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帮助 读者 快速 邵 琉 Spring 源 码 ， 以 便 对 Spring 源码 进行 扩展 或 修改 ， 从 而 满足 业务 需求 
* 所 有 知识 点 均 以 HelloWorld 级 别 示 例 为 切入 点 ， 描 述 简单 之 后 的 复杂 
对 于 复杂 逻辑 的 讲解 采用 剥 洋 瓯 似 的 方式 ， 层 层 分 解 : 度 ， 便 于 读者 理解 和 掌握 
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源 代码 的 重要 性 

Java 开 发 人 员 都 知道 ， 阅 读 源 人 码 是 一 个 非常 好 的 学 习 方 式 ， 在 我 们 
日 常 工作 中 或 多 或 少 都 会 接触 一 些 开源 代码 ， 比 如 说 最 第 用 的 Struts、 
Hibernate、Spring， 这 些 源 码 的 普及 与 应 用 程度 远 远 超过 我 们 的 想象 ， 
正 因 为 很 多 人 使 用 ， 也 在 推动 着 源码 不 断 地 去 完善 。 这 些 优秀 的 源码 中 
有 着 多 年 积淀 下 来 的 精华 ， 这 些 精华 是 非常 值得 我 们 学 习 的 ， 不 管 我 们 
当前 是 什么 水 平 ， 通 过 反复 阅读 源码 能 力 能 有 所 提升 ， 小 到 对 源码 所 提 
供 的 功能 上 的 使 用 更 加 熟练 ， 大 到 使 我 们 的 程序 设计 更 加 完美 优秀 。 但 
是 ， 纵 观 我 们 映 边 的 人 人， 能 够 做 到 通读 源码 的 真 的 是 少 之 又 少 ， 究 其 原 
因 不 外 平 以 下 几 点 。 

阅读 源码 绝对 算得 上 是 一 件 费 时 费力 的 工作 ， 需 要 读者 耗费 大 量 的 
时 间 去 完成 。 而 作为 开发 人 员 ， 毕 苋 精力 有 限 ， 实 在 没 办 法 拿 出 太 多 的 
时 间 放 在 源码 的 阅读 上 。 

源码 的 复杂 性 。 任 何 一 款 源 码 经 历 了 多 年 的 发 展 与 提炼 ， 其 复杂 程 
度 可 想 而 知 。 当 我 们 阅读 源码 的 时 候 ， 大 家 都 知道 需要 通过 工具 来 跟踪 
代码 的 运行 ， 进 而 去 分 析 程 序 。 但 是 ， 当 代码 过 于 复杂 ， 环 环 相 扣 组 来 
组 去 的 时 候 ， 跟 进 了 几 十 个 甚至 几 上 下 个 函数 后 ， 这 时 我 们 已 经 不 知道 自 
己 所 处 的 位 置 了 ， 不 得 不 再 重 来 ， 但 是 一 次 又 一 次 的 ， 最 终 发 现 自己 根 
本 无 法 驾驭 它 ， 不 得 不 放弃 。 

有 些 源 码 发 展 多 年 ， 会 遇 到 各 种 各 样 的 问题 ， 并 对 问题 进行 了 解 
决 ， 而 这 些 问 题 有 的 对 于 我 们 来 说 甚至 可 以 用 英名 其 妙 来 修饰 ， 有 时候 
根本 想 不 出 会 在 什么 情况 下 会 发 生 。 我 们 选择 各 种 查阅 资料 ， 碍 询 无 
果 ， 失 去 耐心 ， 最 终 放弃 。 

无 论 基 于 什么 样 的 原因 ， 放 弃 疯 读 源 码 始终 不 是 一 个 明智 的 选择 ， 





























因为 你 失去 了 一 个 跟 大 师 学 习 的 机 会 。 而 且 ， 当 你 读 过 几 个 源码 之 后 你 
会 太 现 ， 他 们 的 思想 以 及 实现 方式 是 相通 的 。 这 束 是 开源 的 好 处 。 随 着 
各 种 开源 软件 的 发 展 ， 各 家 都 会 融合 别家 优秀 之 处 来 不 断 完善 自己 ， 这 
样 ， 到 最 后 的 结果 就 是 所 有 的 开源 软件 从 设计 上 或 者 实现 上 都会 变 得 越 
来 越 相 似 ， 也 残 是 说 当 你 读 完 菜 个 优秀 源码 后 再 去 读 为 一 个 源 代 码 ， 速 
度 会 有 很 大 提升 。 

以 我 为 例 ，Spring 古 我 阅读 的 第 一 个 源码 ， 几 乎 耗 尽 了 我 将 近 半 年 
的 时 间 ， 其 中 各 种 十 效 可 想 而 知 ， 但 是 当 我 读 完 Spring 再 去 读 MyBatis 只 
用 了 两 周 时 间 。 当 然 ， 暂 且 不 论 它 们 的 复杂 程度 不 同 ， 至 少 我 阅读 的 时 
候 发 现 有 很 多 相通 的 东西 。 当 你 第 一 次 阅读 的 时 候 ， 你 的 重点 一 定 是 在 
源码 的 理解 上 ， 但 是 ， 当 你 读 完 第 一 个 源码 再 去 读 下 一 个 的 时 候 ， 你 目 
然而 然 地 会 带 着 批判 或 者 说 挑剔 的 眼光 去 阅读 : 为 什么 这 个 功能 在 我 之 
前 看 的 源码 中 是 那样 实现 的 ， 而 在 这 里 会 是 这 样 实现 的 ? 这 其 中 的 道理 
在 哪里 ， 哪 种 实现 方式 更 优秀 呢 ? 而 通过 这 样 的 对 比 及 探索 ， 你 会 及 
现 ， 上 自己 的 进步 快 得 难以 想象 。 

我 们 已 经 有 些 纠结 了， 既然 阅读 源码 有 那么 多 的 好 处 ， 但 是 很 多 同 
学 却 因为 时 间或 者 能 力 的 问题 而 不 得 不 放弃 ， 岂 不 是 太 可 惜 ? 为 了 解决 
这 个 问题 ， 我 撰写 了 本 书 ， 总 结 了 目 己 的 研究 心得 和 实际 项 目 经 验 ， 和 希 
望 能 对 正在 Spring 道 路 上 摸索 的 同仁 们 提供 一 些 帮助 。 

本 书 特 点 

本 书 完全 从 开发 者 的 角度 去 谢 析 源码 ， 每 一 章 都 会 提供 具有 代表 性 
的 实例 ， 并 以 此 为 基础 进行 功能 实现 的 分 析 ， 而 不 是 采取 开篇 就 讲解 什 
么 容 吉 怎么 实现 、AOP 怎 么 实现 之 类 的 写法 。 在 描述 的 过 程 中 ， 本 书 尽 
可 能 地 把 问题 分 解 ， 使 用 刊 洋 黎 的 方式 一 层 一 层 地 将 逻辑 描述 清楚 ， 帮 
助 读者 由 浅 入 深 地 进行 学 习 ， 并 把 这 些 难点 和 问题 各 个 击破 ， 而 不 是 企 
图 一 下 让 读者 理解 一 个 复杂 的 逻辑 。 

在 阅读 源码 的 过 程 中 ， 我 们 难免 会 遇 到 各 种 各 样 的 生 个 功能， 这 些 
































功能 在 特定 的 场合 会 非常 有 用 ， 但 是 可 能 多 数 情况 下 并 不 是 很 常用 ， 甚 
至 都 查阅 不 到 相关 的 使 用 资料 。 本 书 中 重点 针对 这 种 情况 提供 了 相应 的 
实用 示例 ， 让 读者 更 加 全 面 地 了 解 Spring 所 提供 的 功能 ， 对 代码 能 知 其 
然 还 知 其 所 以 然 。 

本 书 按照 每 章 所 提供 的 示例 跟踪 Spring 源码 的 流程 ， 尽 可 能 保证 代 
码 的 连续 性 ， 使 读者 的 思维 不 被 打 乱 ， 让 读者 看 到 Spring 的 执行 流程 ， 
旨 在 尽量 使 读者 在 阅读 完 本 书后 即使 在 不 阅读 Spring 源码 的 情况 下 也 可 
以 对 Spring 源码 进行 优化 ， 甚 至 通过 扩展 源码 来 满足 业务 需求 ， 这 对 开 
发 人 员 来 说 是 一 个 很 高 的 要 求 。 本 书 就 希望 能 帮助 读者 全 面 提 升 实战 能 
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本 书 结 构 

本 书 分 为 两 部 分 : 核心 实现 和 企业 应 用 。 

第 一 部 分 核心 实现 《第 1 一 7 章 ) : 是 Spring 功能 的 基础 ， 也 是 企业 
应 用 部 分 的 基础 ， 主 要 对 容器 以 及 AOP 功 能 实现 做 了 具体 的 分 析 ， 如 果 
读者 之 前 没有 接触 过 Spring 源 代码 ， 建 议 认 真 阅读 这 个 部 分 ， 否 则 阅读 
企业 应 用 部 分 时 会 比较 吃力 。 

第 二 部 分 企业 应 用 【第 8 一 13 章 ) : 在 核心 实现 部 分 的 基础 上 围绕 
企业 应 用 常用 的 模块 进行 讨论 ， 这 些 模块 包括 Spring 整合 JDBC、Spring 
整合 MyBatis、 事 务 、SpringMVC、 远 程 服 务 、Spring 消息 服务 等 ， 骨 
在 帮助 读者 在 日 常 开发 中 更 加 高 效 地 使 用 Spring。 

本 书 适用 的 Spring 版 本 

截至 完稿 ，Spring 已 经 发 布 了 4.0.0.M1 版 本 。 本 书 虽 然 是 基于 
Spring 3.2 版 本 编写 的 ， 但 所 讨论 的 内 容 都 属于 Spring 的 基础 和 常用 的 功 
能 ， 这 些 功 能 都 经 过 长 时 间 、 大 量 用 户 的 验证 ， 已 经 非常 成 熟 ， 改 动 的 
可 能 性 相对 较 小 。 而 且 从 目前 Spring 的 功能 规划 来 看 ， 本 书 所 涉及 的 内 
容 并 不 在 Spring 未 来 改动 的 范围 内 ， 因 此 在 未 来 的 很 长 一 段 时 间 内 本 书 
都 不 会 过 时 的 。 
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的 第 用 功能 。 所 有 观点 都 出 自作 者 的 个 人 见解 ， 下 漏 、 错 误 之 处 在 所 难 
免 ， 欢 迎 大 家 指正 。 读 者 如 果 有 好 的 建议 或 者 学 习 本 书 过 程 中 遇 到 问 
题 ， 请 发 送 邮 件 到 haojia_007@163.com， 和 希望 能 够 与 大 家 一 起 交流 和 进 
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优秀 的 开源 代码 并 从 中 进行 总 结 ， 从 而 实现 个 人 技能 的 提高 ， 尤 其 对 
Spring、Hibernate、MyBatis、JMS、Tomcat 等 源码 有 着 深刻 的 理解 和 认 
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第 1 章 ” ”Spring 整体 架构 和 环境 搭建 


Spring 是 于 2003 年 兴起 的 一 个 轻 量 级 的 Java 开 源 框架 ， 由 Rod 
Johnson 在 其 著作 《Expert One-On-One J2EE Development and Design) "F 
阐述 的 部 分 理念 和 原型 衍生 而 来 。Spring 是 为 了 解决 企业 应 用 开发 的 复 
杂 性 而 创建 的 ， 它 使 用 基本 的 JavaBean 来 完成 以 前 只 可 能 由 EJB 完 成 的 
事情 。 然 而 ，Spring 的 用 途 不 仅 限 于 服务 器 问 的 开发 。 从 简单 性 、 可 测 
试 性 和 松 耦 合 的 角度 而 言 ， 任 何 Java 应 用 都 可 以 从 Spring 中 受益 。 


1.1 Spring ARR 





Spring 框架 是 一 个 分 层 架 构 ， 它 包含 一 系列 的 功能 要 素 ， 并 被 分 为 
大 约 20 个 模块 ， 如 图 1-1 所 示 。 


Expression 
Language 





图 1-1 Spring 整体 架构 图 


这 些 模 块 被 总 结 为 以 下 几 部 分 。 
(1) Core Container. 

Core Container Z LR) (147A Core, Beans. Context#il 
Expression Language ZA. 

Core 和 Beans 模 块 是 框架 的 基础 部 分 ， 提 供 IoC《〈 转 控制 ) 和 依赖 注 
入 特性 。 这 里 的 基础 概念 是 BeanFactory， 它 提供 对 Factory 模 式 的 经 典 实 
现 来 消除 对 程序 性 单 例 模式 的 需要 ， 并 真正 地 允许 你 从 程序 逻辑 中 分 离 
出 依赖 关系 和 配置 。 

Core 模 块 主要 包含 Spring 框架 基本 的 核心 工具 类 ，Spring 的 其 他 组 
件 要 都 要 使 用 到 这 个 包 里 的 类 ，Core 模 块 是 其 他 组 件 的 基本 核心 。 当 然 
你 也 可 以 在 自己 的 应 用 系统 中 使 用 这 些 工 具 类 。 

Beans 模 块 是 所 有 应 用 都 要 用 到 的 ， 它 包含 访问 配置 文件 、 创 建 和 
管理 bean 以 及 进行 Inversion of Control / Dependency Injection CIoC/DI) 
操作 相关 的 所 有 类 。 

Context 模 块 构 建 于 Core 和 Beans 模 块 基础 之 上 ， 提 供 了 一 种 类 似 于 
JNDI 注 册 器 的 框架 式 的 对 象 访问 方法 。Context 模 块 继承 了 Beans 的 特 
性 ， 为 Spring 核心 提供 了 大 量 扩展 ， 添 加 了 对 国际 化 《例如 资源 绑 
E) 、 事 件 传播 、 资 源 加 载 和 对 Context 的 透明 创建 的 支持 。Context 模 
块 同时 也 支持 J2EE 的 一 些 特性 ， 例 如 EJB、JMX 和 基础 的 远程 处 理 。 
ApplicationContext 接 口 是 Context 模 块 的 关键 。 

Expression Language 模块 提供 了 一 个 强大 的 表达 式 语 言 用 于 在 运行 
时 查询 和 操纵 对 象 。 它 是 JSP 2.1 规 范 中 定义 的 unifed expression 
language 的 一 个 扩展 。 该 语言 文 持 设置 /获取 属性 的 值 ， 属 性 的 分 配 ， 方 
法 的 调用 ， 访 问 数组 上 下 文 Caccessiong the context of arrays) 、 容 器 和 
Zub. WMA KGAA. a4 eel) A Springh IoC 容 器 中 根据 
名 称 检 索 对 象 。 它 也 文 持 list 投 影 、 选 择 和 一 般 的 list 聚 合 。 


(2) Data Access/Integration 。 











Data Access/Integration 层 包含 有 JDBC、ORM、OXM、JMS 和 
Transaction 模 块 ， 其 中 : 

JDBC 模 块 提供 了 一 个 JDBC 抽 象 屋 ， 它 可 以 消除 见长 的 JDBC 编 码 
和 解析 数据 库 广 商 特有 的 错误 代码 。 这 个 模块 包含 了 Spring 对 JDBC 数 据 
访问 进行 封装 的 所 有 类 。 

ORM 模 块 为 流行 的 对 象 -关系 映 冉 API， 如 JPA、JDO、Hibernate、 
iBatis 等 ， 提 供 了 一 个 交互 层 。 利 用 ORM 封 装 包 ， 可 以 混合 使 用 所 有 
Spring 提供 的 特性 进行 O/R 上 映射。 如 前 边 提 到 的 简单 声明 性 事物 管理 。 

Spring 框架 插入 了 香干 个 ORM 框 架 ， 从 而 提供 了 ORM 的 对 象 天 系 
工具 ， 其 中 包括 JDO、Hibernate 和 iBatisSQL Map 。 所 有 这 些 都 遵从 
Spring 的 通用 事务 和 DAO 异 常 层次 结构 。 

OXM 模 块 提 供 了 一 个 对 Object/XML 了 映射 实 现 的 抽象 层 ， 
ObjectVXML 了 映射 实现 包括 JAXB、Castor、XMLBeans、JiBX 和 
XStream. 

JMS (Java Messaging Service) 模块 主要 包含 了 一 些 制造 和 消费 消 
EARTE. 

Transaction 模块 支持 编程 和 声明 性 的 事物 管理 ， 这 些 事物 类 必须 实 
现 特 定 的 接口 ， 并 且 对 所 有 的 POJO 都 适用 。 

(3) Web。 

Web 上 下 文 模块 建立 在 应 用 程序 上 下 文 模块 之 上 ， 为 基于 Web 的 应 
用 程序 提供 了 上 下 文 。 所 以 ， Spring 框架 支持 与 Jakarta Struts 的 集成 。 
Web 模 块 还 简化 了 处 理 多 部 分 请 求 以 及 将 请 求 参 数 绑 定 到 域 对 象 的 工 
1E. Web/z& 4 f Web. Web-Servlet, Web-Struts fI Web-Porleti E, .H. 
体 说 明 如 下 。 

Web 模 块 : 提供 了 基础 的 面 同 Web 的 集成 特性 。 例 如 ， 多 文件 上 
传 、 使 用 servlet listeners] in 4, 1o0C Ris UJ — ^ IBI I8) Web TI FH EF 
文 。 它 还 包含 Spring 远程 文 持 中 Web 的 相关 部 分 。 














Web-Servlet 模 块 web.servlet.jar: 该 模块 包含 Spring 的 model-view- 
controller (MVC) 实现 。Spring 的 MVC 框 架 使 得 模型 范围 内 的 代码 和 
web forms 之 间 能 够 清楚 地 分 离开 来 ， 并 与 Spring 框架 的 其 他 特性 集成 在 
一 起 

Web-Stmuts 模 块 : 该 模块 提供 了 对 Struts 的 文 持 ， 使 得 类 在 Spring 应 
用 中 能 够 与 一 个 典型 的 Struts Web 层 集成 在 一 起 。 注 意 ， 该 文 持 在 Spring 
3.0 中 是 deprecated 的 。 

Web-Porlet 模 块 : 提供 了 用 于 Portlet 环 境 和 Web-Servlet 模 块 的 MVC 
的 实现 。 

(4) AOP。 

AOP 模 块 提供 了 一 个 符合 AOP 联 盟 标准 的 面 同 切 面 编程 的 实现 ， 它 
让 你 可 以 定义 例如 方法 拦截 器 和 切 点 ， 从 而 将 逻辑 代码 分 开 ， 降 低 它 们 
之 间 的 耦合 性 。 利 用 source-level 的 元 数据 功能 ， 还 可 以 将 各 种 行为 信 
恩 合 并 到 你 的 代码 中 ， 这 有 点 像 .Net 技 术 中 的 attribute 概 念 。 

通过 配置 管理 特性 ，Spring AOP 模 块 直接 将 面向 切面 的 编程 功能 
成 到 了 Spring 框 架 中 ， 所 以 可 以 很 容易 地 使 Spring 框 架 写 理 的 任何 对 象 
支持 AOP。Spring AOP 模 块 为 基于 Spring 的 应 用 程序 中 的 对 象 提供 了 事 
务 管理 服务 。 通 过 使 用 Spring AOP， 不 用 依赖 EJB 组 件 ， 就 可 以 将 声明 
性 事务 管理 集成 到 应 用 程序 中 。 

Aspects 模 块 提 供 了 对 AspectJ 的 集成 文 持 。 

Instrumentation 模 块 提供 了 class instrumentation x #4 classloader 实 
现 ， 使 得 可 以 在 特定 的 应 用 服务 器 上 使 用 。 

(5) Test。 
Test 模 块 支持 使 用 JUnit 和 TestrNG 对 Spring 组 件 进行 测试 。 








1.2 环境 搭建 


Spring 已 经 将 源码 从 svn 迁 移 到 了 GitHub。 而 且 也 改 为 基于 Gradle 的 
构建 来 构建 项 目 ， 它 取代 了 之 前 的 Ant+Ivy 系 统 ， 所 以 要 构建 Spring 源码 
环境 首先 要 安装 GitHub 以 及 Gradle。 


1.2.1 安装 GitHub 


自 先 读者 需要 a 到 GitHub 官 网 去 下 载 安装 包 ， 其 中 Windows 系 统 对 应 
的 版 本 下 载 地 址 为 : http://windows.github.com/， 下 载 后 双击 进行 安装 。 
Bae MIVA, Rs Ph GitHub 的 沫 单 ， 如 图 1-2 所 示 。 








|. GitHub, Inc 
Q Git Shell 默认 程序 
© GitHub online support 
© GitHub 

p HP 


4 ”返回 





IEEE 


图 1-2 HitHub zi Jk: I] Je Se 8e 


1.2.2 安装 Gradle 


Gradle 是 一 个 基于 Groovy 的 构建 工具 ， 它 使 用 Groovy 来 编写 构建 肢 
本 ， 文 持 依 赖 管理 和 多 项 目 创建 ， 类 似 Maven， 但 比 其 更 加 简单 轻便 。 
Gradle 为 Ivy 提供 了 一 个 layer， 提 供 了 build-by-convention 集成 ， 而 且 
它 还 让 你 获得 许多 类 似 Maven 的 功能 。 你 可 以 从 http://www. 
gradle.org/downloads 页 面 下 载 Gradle ， 下 载 后 将 文件 解压 放 到 指定 目录 
中 (笔者 放 在 了 C:\Program Files 目 录 下 ) ， 然 后 开始 进行 环境 变量 的 配 
置 。 











(1) 根据 对 应 目录 创建 GRADLE_HOME 系 统 变量 ， 如 图 1-3 所 


Ze 
(20 将 系统 变量 加 入 到 path 中 ， 如 图 1-4 所 示 。 





SBE IS — 
变量 名 他) GRADLE HONME 


zu v) 














图 1-3 创 建 对 应 于 Gralde 的 系统 变量 








编 卓 系统 变量 — 
zr e OD Path 
SBA cv) NJAVA HOMES Nbin; ETAT ITE 
确定 取消 











图 1-4 将 Gradle 对 应 的 系统 变量 加 入 path 中 
(3) 测试 。 
当 完 成 系统 变量 的 配置 后 打开 命令 窗口 输入 命令 “gradle -version", 
如 果 安 装 成 功 会 出 现 Gradle 对 应 的 版 本 信息 ， 如 图 1-5 所 示 。 


C: Nisers Vidministrator»gradle -version 





图 1-5 测试 Gradle 的 环境 变量 配置 


1.2.3 ¿Sprin 


为 Spring 源码 是 通过 GitHub 进 行 管理 的 ， 所 以 我 们 首先 打开 


GitHub， 单 击 快捷 菜单 中 的 “Git Shell* 选 项 ， 如 图 1-6 所 示 。 





GitHub, Inc 

Q Git Shell 

€» GitHub online support 
QO GitHub 


图 1-6 启动 GitHub 启 动 菜单 


打开 GitHub 后 ， 你 可 以 通过 cd 命令 将 当前 操作 目录 转换 到 我 们 想 要 
存储 源码 的 目录 ， 例 如 ， 想 要 将 下 载 的 源码 存储 到 e:\test 下 ， 则 可 以 执 
行 “cd e:\test”。 

输入 以 下 命令 : 

git clone git://github.com/SpringSource/Spring-framework.git 

其 中 “git://github.com/SpringSource/Spring-framework.git” 为 Spring 的 
源码 地 址 。 执 行 命令 后 便 进入 源码 下 载 状 态 ， 如 图 1-7 所 示 。 


= oo = | we comma 
yes SER: CA\Windows\System32\WindowsPowerShell\v1.0\Powershell.exe c8 BR 


Windows PowerShell 
版 权 所 有 <C> 2089 Microsoft Corporation. {FE ATA A 


iC: Wsers Administrator\Desktop> cd E:\test 

E:\test> git clone git://github.com/SpringSource/spring—f ramework.git 
Cloning into ’spring-framework’ ... 

remote: Counting objects: 1536801, done. 

remote: Compressing objects: 168% (48477748477). done. 

Receiving objects: 1% (176771536601), 476.8080 KiB i 5 KiB/s 





图 1-7 使 用 GitHub 开 始 下 载 源码 





经 过 一 段 时 间 的 等 待 后 源码 下 载 结束 ， 窗 口 状态 如 图 1-8 所 示 。 


上 SER: C:’\Windows\System32\WindowsPowerShell\v1.0\Powershell.exe ES OX 


PowerShe 11] 
<C> 26869 Microsoft Corporation 


rs \Administrator\Desktop> cd E: 
t> git clone git github.com/S pringSource/spring-f ranework.git 


'spring-framevork'... 


Cloning into 
remote: Counting objects: 153601. done. 

remote: Compressing objects: 188% (48477748477), done. 

remote: Total 153601 <delta 85298). reused 149908 <delta 82093) 
Receiving objec 166% (1536617153661). 34.01 MiB : 8 KiB/s. done. 
Resolving deltas: 166% (85208785208). done. 

Checking out files: 160% (607376073). done. 


E:\test> 








图 1-8 源码 下 载 结束 的 窗口 显示 


而 这 时 候 我 们 去 查看 ， 对 应 的 文件 夹 下 已 经 存在 了 相应 的 源码 信 
息 ， 如 图 1-9 所 示 。 





git e. spring-tx 
@ settings e. spring-web 
@ buildSrc e. spring-webmvc 
&. gradle $4. spring-webmvc-portlet 
e. spring-aop e. spring-webmvc-tiles3 
e. spring-aspects e. spring-websocket 
@ spring-beans @ src 
e. spring-context & -gitignore 
@ spring-context-support $9 build.gradle 
@ spring-core wm | CONTRIBUTING.md 
@ spring-expression 好 | gradle.properties 
e. spring-instrument & | gradlew 
& spring-instrument-tomcat |g) gradlew.bat 
e. spring-jdbc Mi mport-into-eclipse.bat 
e. spring-jms $9 | import-into-eclipse.sh 
e. spring-orm & | import-into-idea.md 
@ spring-orm-hibernate4 £j | README.md 
@ spring-oxm $9 settings.gradle 
@ spring-test 
@ spring-test-mvc 


图 1-9 下 载 的 Spring 源码 








但 是 当前 的 源码 并 不 可 以 直接 导入 Eclipse 中 ， 我 们 还 需要 将 源码 转 
换 为 Eclipse 可 以 读 取 的 形式 。 网 上 有 各 种 各 样 的 方法 ， 其 中 出 现 最 多 的 
是 告诉 大 家 将 所 有 工程 一 次 性 的 编译 、 导 入 ， 但 是 笔者 并 不 推荐 这 样 的 
方式 ， 因 为 这 样 会 耗费 大 量 的 时 间 ， 而 且 当 存在 编译 错误 的 时 候 你 不 得 
不 重新 编译 。 笔 者 建议 只 对 我 们 感 兴趣 的 工程 进行 Eclipse 工程 转换 ， 
比如 我 们 想 要 得 看 Spring 事务 部 分 的 源码 ， 打 开 命 令 窗口 ， 将 当前 目录 
切换 至 源码 所 在 目录 ， 例 如 ， 这 里 是 Spring-tx 文 件 夹 下 ， 执 行 命 
& “gradle cleanidea eclipse”， 当 窗口 出 现 如 下 状态 说 明 已 经 开始 执行 转 
换 过 程 ， 如 图 1-10 所 示 。 





D:=\test \spring—f ramework\spring—-tx>gradle cleanIdea eclipse 


:huildSrc:compiledJava 


:huildSsrc:compileGroovy 





:huildSrc:processResources 


图 1-10 Spring 源码 转换 至 eclipse 工 程 


经 过 一 段 时 间 后 转换 成 功 ， 如 图 1-11 所 示 。 

这 时 ， 我 们 再 得 看 对 应 的 文件 夹 会 有 发现， 已 经 出 现 了 作为 Eclipse 
工程 所 必须 的 .project 与 .classpath 文 件 了 ， 如 图 1-12 所 示 。 

打开 Eclipse， 将 工程 导入 ， 导 入 后 如 网 1-13 所 示 。 


"ESO 
: Spr 
:Spr 
:Spr 
-Spr 
: Spr 


ing—tx: 
ing-tx: 
ing-tx: 
ing-tx: 
ing-tx: 
ing-tx: 





eclipseJdtPrepare 
eclipseJdt 
eclipseProject 
eclipseSettings 

ec lipseWst Component 
eclipse 


BUILD SUCCESSFUL 


otal time: 


52.511 secs 


D=\test \spring-f ramevwork\spring-tx> 





图 1-11 Spring 源码 成 功 转换 至 eclipse 工 程 








settings 
bin 

@ src 

2) .classpath 


4) project 


图 1-12 转 换 至 Eclipse 工程 后 的 Spring 源码 结构 


4 82 spring-tx 
“> (9 srcfmain/java 

b (S8 src/main/resources 

> (8 src/test/java 

> (9 src/test/resources 

> mà Referenced Libraries 
& bin 

> @ src 


图 1-13 导 入 Eclipse 后 的 源码 工程 








你 会 发 现 工程 名 称 前 面 有 一 个 感叹 号 ， 这 说 明 存 在 错误 。 碍 看 依赖 
包 及 工程 ， 会 看 到 当前 工程 所 依赖 的 包 已 经 完全 导入 ， 没 有 问题 ， 工 程 
所 依赖 的 JAR 如 图 1-14 所 示 。 


^ Order and Export 


JARs and class folders on the build path: 





BA Libraries 

















G8 aopalliance-1.0jar - C\Users\Administrator\.gradl Add JARs... 
i9 aspectjweaver-1.7.2jar - C\Users\Administrator\.c 
Gi connector-api-1.5jar - CAUsers\Administrator\.gré 
m ejb-api-3.0jar - C:\Users\Administrator\.gradle\ca "rmn 
Gt hamcrest-all-1.3jar - CAUsers\Administrator\.grac 
59 hamcrest-core-1.3jar - C:\Users\Administrator\.gr Add Library... 
i» javax.persistence-2.0.0jar - CAUsersVAdministratoi 
Qs) javax.transaction-api-1.2-b03jar - CAUsers\Admin 
Qa junit-4.11 jar - C:\Users\Administrator\.gradle\cact| | Add External Class Folder... 
i» mockito-core-1.9.5jar - CAUsersVAdministratorl.g 


Add External JARs... 


Add Class Folder... 





Qe objenesis-1.0jar - C:\Users\Administrator\.gradle\ | Edit... 
(wa uow-6.0.2.17 jar - C:\Users\Administrator\.gradle\¢ - 
mi JRE System Library [jdk1.5.0 07] | Remove 





Migrate JAR File... 














图 1-14 工程 依赖 的 JAR 


但 是 ， 碍 看 依赖 的 Projects 时 发 现 ， 当 前 工程 还 要 依赖 于 其 他 Spring 
中 的 6 个 工程 ， 这 时 ， 读 者 可 以 选择 以 同样 的 方式 继续 导入 源码 工程 ， 
或 者 ， 直 接 找 到 对 应 的 JAR 加 入 编译 路 径 ， 工 程 所 依赖 的 Projects 如 图 1- 
15 所 示 。 





À 6 build path entries are missing. ~ vv 





(9 Source | = Projects | m Libraries E Order and Export 


Required projects on the build path: 





lg? spring-aop (missing) Add... | 
b? spring-beans (missing) 
lg? spring-context (missing) Edit... 


lg? spring-core (missing) 
i=} spring-expression (missing) 
b? spring-instrument (missing) 














图 1-15 工程 所 依赖 的 Projects 


第 2 音 ” 容 器 的 基本 实现 


源码 分 析 是 一 件 非常 前 熬 非 常 有 挑战 性 的 任务 ， 你 准备 好 开始 战斗 
了 吗 ? 

在 正式 开始 分 析 Spring 源码 之 前 ， 我 们 有 必要 先 来 回顾 一 下 Spring 
中 最 简单 的 用 法 ， 尽 管 我 相信 您 已 经 对 这 个 例子 非常 熟悉 了 。 


2.1 容器 基本 用 ; 


bean 是 Spring 中 最 核心 的 东西 ， 因 为 Spring 就 像 是 个 大 水 桶 ， 而 bean 
就 像 是 容器 中 的 水 ， 水 桶 脱离 了 水 便 也 没什么 用 处 了 ， 那 么 我 们 先 看 看 
bean 的 定义 。 
public class MyTestBean { 
private String testStr = "testStr"; 
public String getTestStr() { 
return testStr; 
} 
public void setTestStr(String testStr) { 
this.testStr = testStr; 


} 

很 普通 ，bean 没 有 任何 特别 之 处 ， 的 确 ，Spring 的 目的 就 是 让 我 们 
的 bean 能 成 为 一 个 纯粹 的 POJO， 这 也 是 Spring 所 退 求 的 。 接 下 来 看 看 配 
置 文件 : 

<?xml version="1.0" encoding="UTF-8"?> 

«beans xmlns-"http://www.Springframework.org/schema/beans" 


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www. Springframework. 
org/schema/beans/Spring-beans.xsd"> 
<bean id="myTestBean" class="bean.MyTestBean"/> 
</beans> 
在 上 面 的 配置 中 我 们 看 到 了 bean 的 声明 方式 ， 尽 管 Spring 中 bean 的 
元 际 定 义 着 N 种 属性 来 文 撑 我 们 业务 的 各 种 应 用 ， 但 是 我 们 只 要 声明 成 
这 样 ， 基 本 上 就 已 经 可 以 满足 我 们 的 大 多 数 应 用 了 。 好 了 ， 你 可 能 觉得 
还 有 什么 ， 但 是 ， 真 没 了 ，Spring 的 入 门 示例 到 这 里 已 经 结束 ， 我 们 可 
以 写 测试 代码 测试 了 。 
@SuppressWarnings("deprecation") 











public class BeanFactoryTest { 
@Test 
public void testSimpleLoad(){ 
BeanFactory bf = new XmlBeanFactory(new ClassPathResource ( 
"beanFactoryTest.xml")); 
MyTestBean bean-(MyTestBean) bf.getBean("myTestBean"); 
assertEquals("testStr",bean.getTestStr()); 


} 

相信 聪明 的 读者 会 很 快 看 到 我 们 期 望 的 结果 : 在 Eclipse 中 显示 了 
Green Bar。 

直接 使 用 BeanFactory 作 为 容器 对 于 Spring 的 使 用 来 说 并 不 多 见 ， 甚 
至 是 甚 少 使 用 ， 因 为 在 企业 级 的 应 用 中 大 多 数 都 会 使 用 的 是 
ApplicationContext (a2 PRNSTA EN ZHAN KA) ， 这 里 只 是 
用 于 测试 ， 让 读者 更 快 更 好 地 分 析 Spring 的 内 部 原理 。 

OK， 我 们 又 复习 了 一 避 Spring， 你 是 不 是 会 很 不 届 呢 ?这 样 的 小 例 








子 没 任何 挑战 性 。 嗯 ， 确 实 ， 这 样 的 使 用 是 过 于 简单 了 ， 但 是 本 书 的 目 
的 并 不 是 介绍 如 何 使 用 Spring， 而 是 帮助 您 更 好 地 了 解 Spring 的 内 部 原 
理 。 读 者 可 以 自己 先 想 想 ， 上 面 的 一 句 简单 代码 都 执行 了 什么 样 的 逻辑 
We? 这 样 一 句 简单 代码 其 实在 Spring 中 执行 了 太 多 太 多 的 逻辑 ， 即 使 笔 
者 用 半 本 书 的 文字 也 只 能 介绍 它 的 大 致 原理 。 那 么 就 让 我 们 快速 的 进入 
分 析 状 态 吧 。 


2.2 功能 分 析 


现在 我 们 可 以 来 好 好 分 析 一 下 上 面 测试 代码 的 功能 ， 来 探索 上 面 的 
测试 代码 中 Spring 完 竟 帮助 我 们 完成 了 什么 工作 ? 不 管 之 前 你 是 否 使 用 
过 Spring， 当 然 ， 你 应 该 使 用 过 的 ， 毕 竟 本 书面 用 的 是 对 Spring 有 一 定 
使 用 经 验 的 读者 ， 你 都 应 该 能 猜 出 来 ， 这 上段 测试 代码 完成 的 功能 无 非 就 
FELL PILE © 

(1) 读 取 配置 文件 beanFactoryTest.xml。 

(2) 根据 beanFactoryTest.xml 中 的 配置 找到 对 应 的 类 的 配置 ， 并 
实例 化 。 

(3) 调用 实例 化 后 的 实例 。 

为 了 更 清楚 地 描述 ， 笔 者 临时 画 了 设计 类 图 ， 如 图 2-1 所 示 ， 如 采 
想 完成 我 们 预想 的 功能 ， 至 少 需 要 3 个 类 。 











ReflectionUtil ConfigReader 
| —— À—ÀMÀ] 


图 2-1 最 简单 的 Spring 功能 架构 


ConfigReader: 用 于 读 取 及 验证 配置 文件 。 我 们 要 用 配置 文件 里 面 
的 东西 ， 当 然 首 先 要 做 的 就 是 读 取 ， 然 后 放置 在 内 存 中 。 

ReflectionUtil: 用 于 根据 配置 文件 中 的 配置 进行 反射 实例 化 。 比 如 
在 上 例 中 beanFactoryTest.xml 出 现 的 <bean id="myTestBean" 
class-"bean.MyTestBean'/», 4/4150 n] EA bean. My TestBean3it £T S451 
化 。 

App: 用 于 完成 整个 逻辑 的 串联 。 

按照 最 原始 的 思维 方式 ， 整 个 过 程 无 非 如 此 ， 但 是 作为 一 个 风靡 世 
界 的 优秀 源码 真 的 就 这 么 简单 吗 ? 


2.3 工程 搭建 


不 如 我 们 首先 大 致 看 看 Spring 的 源码 。 在 Spring 源码 中 ， 用 于 实 
现 上 面 功能 的 是 org.Springframework.beans.jar， 我 们 看 源码 的 时 候 要 打 
开 这 个 工程 ， 如 果 我 们 只 使 用 上 面 的 功能 ， 那 就 没有 必要 引入 Spring 的 
其 他 更 多 的 包 ， 当 然 Core 是 必须 的 ， 还 有 些 依赖 的 包 如 图 2-2 所 示 。 











CS Source | E Projects | BA Libraries | &; Order and Export | 
JARs and class folders on the build path: 





ad com.springsource.javax.el-1.0.0jar - org.springframework.beans/lib Add JARs... 
ws com.springsource.javax.inject-1.0.0jar - org.springframework.beans/lib 





oe com.springsource.net.sf.cglib-2.2.0.jar - org.springframework.beans/lib Add External JARs... 





os com.springsource.org.apache.commonsJogging-1.1.1jar - org.springframework.beans; Add Meriable 





oe com.springsource.org.apache.og4j-1.2.16 jar - org.springframework.beans/lib 





中 com.springsource.org.easymock-2.5.1.jar - org.springframework.beans/lib Add Library... 


站 com.springsource.org.hamcrest-1.1.0jar - org.springframework.beans/lib 


Add Class Folder... 
oe com.springsource.org.junit-4.9.0.jar - org.springframework.beans/lib dE 


mA JRE System Library [jdk] Add External.Class.Folder««. 























图 2-2 Spring 测试 类 依赖 的 JAR 


引入 依赖 的 JAR 消除 挥 所 有 编译 错误 后 ， 终 于 可 以 看 源码 了 。 或 
许 你 o &3E, Spring 居然 用 了 N 多 代码 实现 了 这 个 看 似 很 简 
单 的 功能 ， 那 么 这 些 代 码 都 是 做 什么 用 的 呢 ? Spring 在 架构 或 者 编码 的 
ic 带 着 疑问 ， 让 我 们 踏 上 了 研读 Spring 源码 的 征 
程 。 
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我 们 首先 尝试 梳理 一 下 Spring 的 框架 结构 ， 从 全 局 的 角度 了 解 一 
Spring 的 结构 组 成 。 

2.4.1 beans 包 的 层级 结 校 


笔者 认为 阅读 源码 的 最 好 方法 是 通过 示例 跟着 操作 一 过 ， 虽 然 有 时 
候 或 者 说 大 多 数 时 候 会 锐 复 傈 的 代码 绕 来 绕 去 ， 绕 到 最 后 已 经 不 知道 上 自 
己 身 在 何 处 了 ， 但 是 ， 如 果 配 以 UML 还 是 可 以 搞定 的 。 笔 者 就 是 按照 





上 自己 的 思路 进行 分 析 ， 并 配合 必要 的 UML， 和 希望 读者 同样 可 以 跟 得 上 
思路 。 
我 们 先 看 看 整个 beans 工 程 的 源码 结构 ， 如 图 2-3 所 示 。 





4 5 org.springtramework.beans 


188 src/main/Java 

(8 src/main/resources 
488 src/test/Java 

(8 src/test/resources 
mA JRE System Library [jdk] 
mA Referenced Libraries 
6 lib 

œ src 

司 beans.iml 

$) build.xml 

x) rvyxml 

im) pom.xml 


template.mf 
图 2-3 beans 工 程 的 源码 结构 


beans 包 中 的 各 个 源码 包 的 功能 如 下 。 
src/main/java 用 于 展现 Spring 的 主要 逻辑 。 
src/main/resources 用 于 存放 系统 的 配置 文件 。 
src/test/java 用 于 对 主要 逻辑 进行 单元 测试 。 
src/test/resources 用 于 存放 测试 用 的 配置 文件 。 


2.4.2 核心 类 介绍 


通过 beans 工 程 的 结构 介绍 ， 我 们 现在 对 beans 的 工程 结构 有 了 初步 
的 认识 ， 但 是 在 正式 开始 源码 分 析 之 前 ， 有 必要 了 解 一 下 Spring 中 最 核 
心 的 两 个 类 。 


1. DefaultListableBeanFactory 

XmlBeanFactory 474 E] DefaultListableBeanFactory, 而 
DefaultListableBeanFactory 是 整个 bean 加 载 的 核心 部 分 ， 是 Spring 注册 
及 加 载 bean 的 默认 实现 ， 而 对 于 XmlBeanFactory 与 
DefaultListableBeanFactory 不 同 的 地 方 其 实 是 在 XmlBeanFactory 中 使 用 
了 自 定 义 的 XML 读 取 器 XmlBeanDefinitionReader， 实 现 了 个 性 化 的 
BeanDefinitionReader 读 取 ，DefaultListableBeanFactory 继 承 了 
AbstractAutowireCapableBeanFactory 并 实现 了 
ConfigurableListableBeanFactory 以 及 BeanDefinitionRegistry 接 口 。 以 下 
是 ConfigurableListableBeanFactory 的 层次 结构 图 〈 见 图 2-4) 以 及 相关 类 
图 ( 见 图 2-5) 。 

从 上 面 的 类 图 以 及 层次 结构 图 中 ， 我 们 可 以 很 清晰 地 从 全 局 角度 了 
解 DefaultListableBean Factory 的 脉络 。 如 果 读 者 没有 了 解 过 Spring 源码 
可 能 对 上 面 的 类 图 不 是 很 理解 ， 不 过 没关系 ， 通 过 后 续 的 学 习 ， 你 会 逐 
渐 了 解 每 个 类 的 作用 。 那 么 ， 让 我 们 先 简单 地 了 解 一 下 上 面 类 图 中 的 各 
个 类 的 作用 。 

AliasRegistry: 定义 对 alias 的 简单 增删 改 等 操作 。 

SimpleAliasRegistry: 主要 使 用 map 作 为 alias 的 缓存 ， 并 对 接口 
AliasRegistry 进 行 实 现 。 

SingletonBeanRegistry: 定义 对 单 例 的 注册 及 获取 。 

BeanFactory: 定义 获取 bean 及 bean 的 各 种 属性 。 

DefaultSingletonBeanRegistry: 对 接口 SingletonBeanRegistry 各 函数 
的 实现 。 

HierarchicalBeanFactory: 继承 BeanFactory， 也 束 是 在 BeanFactory 
定义 的 功能 的 基础 上 增加 了 对 parentFactory 的 支持 。 

BeanDefinitionRegistry: 定义 对 BeanDefinition 的 各 种 增删 改 操作 。 

FactoryBeanRegistrySupport: 在 DefaultSingletonBeanRegistry 基 础 上 





增加 了 对 FactoryBean 的 特殊 处 理 功 能 。 


efaultListableB eanFactory - org.springframework.beans.factory.support 
‘t (31) f E y 
4 DefaultListableB eanFactory 
4 (9^ AbstractAutowireCapableB eanFactory 
4 (9^ AbstractBeanFactory 
4 (9^ FactoryBeanRegistrySupport 
4 (9 DefaultSingletonBeanRegistry 
4 (9 SimpleAliasRegistry 
(9 Object 
Q  AliasRegistry 
© SingletonBeanRegistry 





4 © ConfigurableBeanFactory 
4 © HierarchicalB eanFactory 
Q BeanFactory 
@ SingletonBeanRegistry 
4 9 AutowireCapableBeanFactory 
Q BeanFactory 
4 © BeanDefinitionRegistry 
Q AliasRegistry 
4 © ConfigurableListableB eanFactory 
4 9 AutowireCapableBeanFactory 
Q BeanFactory 
4 @ ConfigurableBeanFactory 
4 €) HierarchicalBeanFactory 
Q BeanFactory 
Q SingletonBeanRegistry 
4 © ListableBeanFactory 
Q BeanFactory 
Q Serializable 








图 2-4 ConfigurableListableBeanFactory 的 层次 结构 图 


* «Java Class» 


© DetaultListableBeanFactory 











一 轩 一 一 
al «Java Class» a «Java Interface» 
© Abstract AutowireCapableBeanFactory Q ConfigurabieListableBeanFactory 
in a m 
A «Java Classe ] a slave Interface» 
© Abstract BeanFactory © AutowireCapabeBeanFactory a 
o [c1 
a) 
al «Java Interface» al «Java Class» a «Java Interface» Java Interface» 
© BeanDefinitionRegistry © FactoryBeanRegistrySupport Q Config urableBeanFactory Q ListableBeanFactory 
全 一 一 —— 同一 一 
m a y 
a Java Class» al «Java Interface» 
© Default SingletonBeanRegist ry Q HierarchicalBeanFactory 
加 一 a A—, zm 
; | | 
7] Java Class» lava Interface» Pljava Interface» 
© SimpleAliasRegistry © SingletonBeanRegist © BeanFactoi 


w 


71«Java Interface» 


Q AliasRegistry 


图 2-5 容器 加 载 相关 类 图 


ConfigurableBeanFactory: 提供 配置 Factory 的 各 种 方法 。 

ListableBeanFactory: 根据 各 种 条 件 获 取 bean 的 配置 清单 。 

AbstractBeanFactory: 综合 FactoryBeanRegistrySupport 和 
ConfigurableBeanFactory 的 功能 。 

AutowireCapableBeanFactory: 提供 创建 beaan、 目 动 注 入 、 初 始 化 以 


及 应 用 bean 的 后 处 理 器 。 

AbstractAutowireCapableBeanFactory: 综合 AbstractBeanFactory 并 对 
接口 Autowire Capable BeanFactory 进 行 实现 。 

ConfigurableListableBeanFactory: BeanFactory 配 置 清单 ， 指 定 忽略 
类 型 及 接口 等 。 

DefaultListableBeanFactory: 综合 上 面 所 有 功能 ， 主 要 是 对 Bean 注 
册 后 的 处 理 。 

XmlBeanFactory 对 DefaultListableBeanFactory 类 进行 了 扩展 ， 主 要 
用 于 从 XML 文档 中 读 取 BeanDefinition， 对 于 注册 及 获取 Bean 都 是 使 用 
从 父 类 DefaultListableBeanFactory 继 承 的 方法 去 实现 ， 而 唯 独 与 父 类 不 
同 的 个 性 化 实现 就 是 增加 了 XmlBeanDefinitionReader 类 型 的 reader 属 
性 。 在 XmlBeanFactory 中 主要 使 用 reader 属 性 对 资源 文件 进行 读 取 和 注 
册 。 

2. XmlBeanDefinitionReader 

XML 配置 文件 的 读 取 是 Spring 中 重要 的 功能 ， 因 为 Spring 的 大 部 分 
功能 都 是 以 配置 作为 切入 点 的 ， 那 么 我 们 可 以 从 
XmlBeanDefinitionReader 中 梳理 一 下 资源 文件 读 取 、 解 析 及 注册 的 大 致 
脉络 ， 首 先 我 们 看 看 各 个 类 的 功能 。 

ResourceLoader: 定义 资源 加 载 器 ， 主 要 应 用 于 根据 给 定 的 资源 文 
件 地 址 返回 对 应 的 Resource。 

BeanDefinitionReader: 主要 定义 资源 文件 读 取 并 转换 为 
BeanDefinition 的 各 个 功能 。 

EnvironmentCapable: 定义 获取 Environment 方 法 。 

DocumentLoader: 定义 从 资源 文件 加 载 到 转换 为 Document 的 功能 。 

AbstractBeanDefinitionReader: 对 EnvironmentCapable、 
BeanDefinitionReader 类 定义 的 功能 进行 实现 。 

BeanDefinitionDocumentReader: 定义 读 取 Docuemnt 并 注册 





BeanDefinition 功 能 。 

BeanDefinitionParserDelegate: 定义 解析 Element 的 各 种 方法 。 

经 过 以 上 分 析 ， 我 们 可 以 梳理 出 整个 XML 配 置 文件 读 取 的 大 致 流 
程 ， 如 图 2-6 所 示 ， 在 XmlBeanDifinitionReader 中 主要 包含 以 下 几 步 的 处 
Hie 


a «Java Class» al «Java Class» 
© XmiBeanDefinitionReader © DefaultBeanDefinitionDoc umentReader 


a «use a “> 
«use» a = z . 
7] «Java Interface» a «Java Class» a «Java Interface» a «Java Class» 
© DocumentLoader (3 AbstractBeanDefinitionReader © BeanDefinitionDocumentReader © BeanDefinitionParserDelegate 
] 加 
^ «Java Interface» 习 «Java Interface» UP sjava Interface» 
O ResourceLoade: © BeanDefinitionRcader O EnvirenmentCapable 


图 2-6 配置 文件 读 取 相 关 类 图 





(1) 通过 继承 上 自 AbstractBeanDefinitionReader 中 的 方法 ， 来 使 用 
ResourLoader 将 资源 文件 路 径 转 换 为 对 应 的 Resource 文 件 。 

(2) 通过 DocumentLoader 对 Resource 文 件 进行 转换 ， 将 Resource 文 
件 转换 为 Document 文 件 。 

(3) 通过 实现 接口 BeanDefinitionDocumentReader 的 
DefaultBeanDefinitionDocumentReader 类 对 Document 进 行 解 析 ， 并 使 用 
BeanDefinitionParserDelegate 对 Element 进 行 解析 。 


2.5 容器 的 基础 XmlBeanFactor 


好 了 ， 到 这 里 我 们 已 经 对 Spring 的 容 占 功能 有 了 一 个 大 致 的 了 解 ， 
尽 绾 你 可 能 还 很 迷糊 ， 但 是 不 要 紧 ， 接 下 来 我 们 会 详细 探索 每 个 步 又 的 


实现 。 再 次 重申 一 下 代码 ， 我 们 接 下 来 要 深入 分 析 以 下 功能 的 代码 实 
E 

BeanFactory bf = new XmlBeanFactory(new 
ClassPathResource("beanFactoryTest.xml")); 

通过 XmlBeanFactory 初 始 化 时 序 图 〈 如 图 2-7 所 示 ) 我们 来 看 一 看 
上 面 代码 的 执行 逻辑 。 


bf:BeanFactoryTest classP athResource:ClassP athResource xmiBeanFactory Xml BeanFactory reader XmiBeanDefinitionReader 


1 new ClassPathResource(*beanF actoryTest xml") 
> 


2 resource Resource 


3: new XmlBeanF actory(resource) 
P. 3.1: loadBeanDefinitions{resource) 


3.2: loadedBeanDefinitionNum:int 


4 bf BeanFactory 


图 2-7 XmlBeanFactory 初 始 化 时 序 图 


时 序 图 从 BeanFactoryTest 测 试 类 开始 ， 通 过 时 序 图 我 们 可 以 一 目 了 
然 地 看 到 整个 逻辑 处 理 顺序 。 在 测试 的 BeanFactoryTest 中 首先 调用 
ClassPathResource 的 构造 函数 来 构造 Resource 资 源 文件 的 实例 对 象 ， 这 
样 后 续 的 资源 处 理 就 可 以 用 Resource 提 供 的 各 种 服务 来 操作 了 ， 当 我 们 
有 了 Resource 后 就 可 以 进行 XmlBeanFactory 的 初始 化 了 。 那 么 Resource 
资源 是 如 何 封装 的 呢 ? 


2.5.1 CES 





Spring 的 配置 文件 读 取 是 通过 ClassPathResource 进 行 封 装 的 ， 如 
new ClassPathResource ("beanFactoryTest.xzml")， 那 么 ClassPathResource 
完成 了 什么 功能 呢 ? 

在 Java 中 ， 将 不 同 来 源 的 资源 抽象 成 URL， 通 过 注册 不 同 的 

handler CURLStreamHandler) 来 处 理 不 同 来 源 的 资源 的 读 取 逻辑 ， 一 般 
handler 的 类 型 使 用 不 同 前 级 (协议 ，Protocol) 来 识别 ， 
如 “file:”、 “http:” “jar:” 等 ， 然 而 URL 没有 默认 定义 相对 Classpath 或 
ServletContext 等 资源 的 handler， 虽 然 可 以 注册 自己 的 URLStreamHandler 
来 解析 特定 的 UREL 前 缀 〈 协 议 ) ， 比 如 “classpath:”， 然 而 这 需要 了 解 
URL 的 实现 机 制 ， 而 且 URL 也 没有 提供 一 些 基 本 的 方法 ， 如 检查 当前 资 
源 是 否 存 在 、 检 查 当 前 资源 是 否 可 读 等 方法 。 因 而 Spring 对 其 内 部 使 用 
到 的 资源 实现 了 自己 的 抽象 结构 : Resource 接 口 来 封装 底层 资源 。 

public interface InputStreamSource { 

InputStream getInputStream() throws IOException; 
} 
public interface Resource extends InputStreamSource { 

boolean exists(); 

boolean isReadable(); 

boolean isOpen(); 

URL getURL() throws IOException; 

URI getURI() throws IOException; 

File getFile() throws IOException; 

long lastModified() throws IOException; 

Resource createRelative(String relativePath) throws IOException; 

String getFilename(); 

String getDescription(); 


InputStreamSource 封 装 任何 能 返回 InputStream 的 类 ， 比 如 File、 
Classpath 下 的 资源 和 Byte Array 等 。 它 只 有 一 个 方法 定义 : 
getInputStream()， 该 方法 返回 一 个 新 的 mputStream 对 象 。 

Resource 接 口 抽 象 了 所 有 Spring 内 部 使 用 到 的 底层 资源 : File. 
URL、Classpath 等 。 首 先 ， 它 定义 了 3 个 判断 当前 资源 状态 的 方法 : df 
在 性 (exists，、 可 读 性 CisReadable) 、 是 否 处 于 打开 状态 

(isOpen) 。 另 外 ，Resource 接 口 还 提供 了 不 同 资源 到 URL、URI、File 
类 型 的 转换 ， 以 及 获取 lastModified 属 性 、 文 件 名 不 带路 径 信 息 的 文件 
4, getFilename()) 的 方法。 为 了 便于 操作 ，Resource 还 提供 了 基于 当 
前 资源 创建 一 个 相对 资源 的 方法 : createRelative()。 在 错误 处 理 中 需要 
详细 地 打印 出 错 的 资源 文件 ， 因 而 Resource 还 提供 了 getDescription() 方 
法 用 于 在 错误 处 理 中 的 打印 信息 。 

对 不 同 来 源 的 资源 文件 都 有 相应 的 Resource 实 现 : 文件 

(FileSystemResource) 、Classpath 资 源 (ClassPathResource) 、URL 资 
W CUrlResource) 、InputStream 资 源 (InputStreamResource) 、Byte 数 
组 (ByteArrayResource) 等 。 相 关 类 图 如 2-8 所 示 。 


© ClassRelativeContext Resource 








© UrlResource © ClassPathResource 
«Java Class» «Java Class» «Java Class» 
© AbstractFileResolvingResource © FiieSystemResource © DescriptiveResource 
= ^ _ 
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«Java Interface» «Java Class» 
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«Java Interface» 
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«Java Interface» 
e InputStream Source 


图 2-8 资源 文件 处 理 相 关 类 图 


«Java Class» 
(9 ByteArrayResource 


在 日 第 的 开发 工作 中 ， 资 源 文 件 的 加 载 也 是 经 第 用 到 的 ， 可 以 直接 
使 用 Spring 提供 的 类 ， 比 如 在 希望 加 载 文件 时 可 以 使 用 以 下 代码 : 


Resource resource-new ClassPathResource(“beanFactoryTest.xml”); 


InputStream inputStream-resource.getInputStream(); 


得 到 inputStream 后 ， 我 们 就 可 以 按照 以 前 的 开发 方式 进行 实现 
了 ， 并 且 我 们 已 经 可 以 利用 Resource 及 其 子 类 为 我 们 提供 好 的 诸多 特 
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有 了 Resource 接 口 便 可 以 对 所 有 资源 文件 进行 统一 处 理 。 至 于 实 


现 ， 其 实 是 非常 简单 的 ， 以 getInputStream 为 例 ，ClassPathResource 中 的 
实现 方式 便 是 通过 class 或 者 classLoader 提 供 的 底层 方法 进行 调用 ， 而 对 
于 FileSystemResource 的 实现 其 实 更 人 简单， 直接 使 用 FileInputStream 对 
文件 进行 实例 化 。 

ClassPathResource.java 

if (this.clazz != null) { 





is = this.clazz.getResourceAsStream(this.path); 
}else { 
is = this.classLoader.getResourceAsStream(this.path); 
} 
FileSystemResource.java 
public InputStream getInputStream() throws IOException { 
return new FileInputStream(this.file); 
} 
当 通 过 Resource 相 关 类 完成 了 对 配置 文件 进行 封装 后 配置 文件 的 读 
取 工 作 就 全 权 交 给 XmlBeanDefinitionReader 来 处 理 了 。 
了 解 了 Spring 中 将 配置 文件 封装 为 Resource 类 型 的 实例 方法 后 ， 
我 们 就 可 以 继续 探寻 XmlBeanFactory 的 初始 化 过 程 了 ，XmlBeanFactory 
NWA FIZ, Spring PEt SRE Me ewer, FEA AT AY 
是 使 用 Resource 实 例 作为 构造 函数 参数 的 办 法 ， 代 码 如 下 : 


XmlBeanFactory.java 

















public XmlBeanFactory(Resource resource) throws BeansException { 
/调用 XmlBeanFactory (Resource,BeanFactory) 构造 方法 ， 
this(resource, null); 
} 
构造 函数 内 部 再 次 调用 内 部 构造 函数 : 
//parentBeanFactory 为 父 类 BeanFactory 用 于 factory 合 并 ， 可 以 为 空 


public XmlBeanFactory(Resource resource, BeanFactory 
parentBeanFactory) throws 

BeansException { 

super(parentBeanFactory); 
this.reader.loadBeanDefinitions(resource); 

} 

上 面 函 数 中 的 代码 this.reader.loadBeanDefinitions(resource) 才 是 资源 
加 载 的 真正 实现 ， 也 是 我 们 分 析 的 重点 之 一 。 我 们 可 以 看 到 时 序 图 中 提 
到 的 XmlBeanDefinitionReader 加 载 数据 就 是 在 这 里 完成 的 ， 但 是 在 
XmlBeanDefinitionReader 加 载 数据 前 还 有 一 个 调用 父 类 构造 函数 初始 化 
的 过 程 : super(parentBeanFactory)， 跟 踪 代 人 码 到 父 类 
AbstractAutowireCapableBeanFactory 的 构造 函数 中 : 


AbstractAutowireCapableBeanFactory.java 








public AbstractAutowireCapableBeanFactory() { 
super(); 
ignoreDependencyInterface(BeanNameA ware.class); 
ignoreDependencyInterface(BeanFactoryA ware.class); 
ignoreDependencyInterface(BeanClassLoaderA ware.class); 

} 

这 里 有 必要 提 及 一 下 ignoreDependencyInterface 方 法 。 
ignoreDependencyInterface 的 主要 功能 是 忽略 给 定 接口 的 自动 装配 功能 ， 
那么 ， 这 样 做 的 目的 是 什么 呢 ? 会 产生 什么 样 的 效果 呢 ? 

举例 来 说 ， 当 A 中 有 属性 B， 那 么 当 Spring 在 获取 A 的 Bean 的 时 候 如 
果 其 属性 B 还 没有 初始 化 ， 那 么 Spring 会 自动 初始 化 B， 这 也 是 Spring 中 
提供 的 一 个 重要 特性 。 但 是 ， 某 些 情况 下 ，B 不 会 被 初始 化 ， 其 中 的 一 
种 情况 就 是 B 实 现 了 BeanNameAware 接 口 。Spring 中 是 这 样 介绍 的 : Él 
动 装配 时 忽略 给 定 的 依赖 接口 ， 典 型 应 用 是 通过 其 他 方式 解析 





Application 上 下 文 注册 依赖 ， 类 似 于 BeanFactory 通过 
BeanFactoryAware 进行 注入 或 者 ApplicationContext 通过 
ApplicationContextAware 进 行 注 入 。 


2.5.2 加 载 Bean 


Z Al $e 21 A 7E XmlBeanFactory 4) ie P 28 p i8] H T 
XmlBeanDefinitionReader 类 型 的 reader 属 性 提供 的 方法 
this.reader.loadBeanDefinitions(resource)， 而 这 人 句 代 码 则 是 整个 资源 加 载 
的 切入 点 ， 我 们 先 来 看 看 这 个 方法 的 时 序 图 ， 如 图 2-9 所 示 。 


xmlBeanFactory XmlBeanFactory reader XmlBeanDefinibonReader encodedResourceEncodedResource || resource Resource inputSourceInputSource 
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RNC NONE pe. 11 newEncodedResource(resource) 


- 
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t get esource() 


13.3: getinputStream() 
13.4: inputSream InputStream 
135 mew InputSource(inputStream) 


136 inputSourceInputSource 


137. doLoadBeanDefinitions((inputSource, encodedResource.getResource())) 
^ 


13 8| lopdedBeanDefinitionNum int 
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2: loadedBeanDefinitionNu 


图 2-9 loadBeanDefinitions 函 数 执行 时 序 图 


看 到 网 2-9 我 们 才 知 道 什 么 叫 山路 十 八 弯 ， 绕 了 这 么 半天 还 没有 真 
正 地 切入 正题 ， 比 如 加 载 XML 文档 和 解析 注册 Bean， 一 直 还 在 做 准备 
工作 。 我 们 根据 上 面 的 时 序 图 来 分 析 一 下 这 里 究竟 在 准备 什么 ? MEM 
的 时 序 图 中 我 们 尝试 梳理 整个 的 处 理 过 程 如 下 。 





C1) 封装 资源 文件 。 当 进入 XmlBeanDefinitionReader 后 首先 对 
参数 Resource 使 用 EncodedResource 类 进行 封装 。 
(2) 获取 输入 流 。 从 Resource 中 获取 对 应 的 InputStream 并 构造 
Input9ource。 
(3) 通过 构造 的 mputSource 实 例 和 Resource 实 例 继续 调用 函数 
doLoadBeanDefinitions 。 
我 们 来 看 一 下 loadBeanDefinitions 函 数 具 体 的 实现 过 程 ; 
public int loadBeanDefinitions(Resource resource) throws 
BeanDefinitionStoreException { 
return loadBeanDefinitions(new EncodedResource(resource)); 
j 
那么 EncodedResource 的 作用 是 什么 呢 ? 通过 名 称 ， 我 们 可 以 大 致 
推 朵 这 个 类 主要 是 用 于 对 资源 文件 的 编码 进行 处 理 的 。 其 中 的 主要 逻辑 
体现 在 getReader() 方 法 中 ， 当 设置 了 编码 属性 的 时 候 Spring 会 使 用 相应 
的 编码 作为 输入 流 的 编码 。 
public Reader getReader() throws IOException { 
if (this.encoding != null) { 
return new InputStreamReader(this.resource.getInputStream(), 
this.encoding); 
} 
else { 


return new InputStreamReader(this.resource.getInputStream()); 


} 
上 面 代码 构造 了 一 个 有 编码 (encoding) 的 InputStreamReader。 当 
构造 好 encodedResource 对 象 后， 再 次 转 入 了 可 复 用 方法 


loadBeanDefinitions(new EncodedResource(resource)). 


这 个 方法 内 部 才 是 真正 的 数据 准备 阶段 ， 也 就 是 时 序 图 所 描述 的 好 
辑 : 
public int loadBeanDefinitions(EncodedResource encodedResource) 
throws BeanDefinitionStoreException { 
Assert.notNull(encodedResource, "EncodedResource must not be 
null"); 
if (logger.isInfoEnabled()) 1 
logger.info("Loading XML bean definitions from " + 
encodedResource. getResource()); 
j 
/通过 属性 来 记录 已 经 加 载 的 资源 
Set<EncodedResource> currentResources = 
this.resourcesCurrently BeingLoaded. get(); 
if (currentResources == null) { 
currentResources = new HashSet<EncodedResource>(4); 
this.resourcesCurrently BeingLoaded.set(currentResources); 
} 
if (!currentResources.add(encodedResource)) { 
throw new BeanDefinitionStoreException( 
"Detected cyclic loading of " + encodedResource + " - check 
your 
import definitions!"); 
} 
try { 
/从 encodedResource 中 获取 已 经 封装 的 Resource 对 象 并 再 次 从 
Resource 中 获取 其 中 的 inputStream 


InputStream inputStream = 


encodedResource.getResource().getInputStream(); 
try 1 
//InputSource 这 个 类 并 不 来 自 于 Spring， 它 的 全 路 径 是 
org.xml.sax.InputSource 
InputSource inputSource = new InputSource(inputStream); 
if (encodedResource.getEncoding() != null) { 
inputSource.setEncoding(encodedResource.getEncoding()); 
j 
/真正 进入 了 逻辑 核心 部 分 
returndoLoadBeanDefinitions(inputSource, 
encodedResource.getResource()); 
} 
finally { 
/关闭 输入 流 


inputStream.close(); 


} 

catch (IOException ex) { 
throw new BeanDefinitionStoreException( 

"IOException parsing XML document from " + 
encodedResource.getResource(), ex); 

} 

finally { 
currentResources.remove(encodedResource); 
if (currentResources.isEmpty()) { 


this.resourcesCurrentlyBeingLoaded.remove(); 


} 
我 们 再 次 整理 一 下 数据 准备 阶段 的 逻辑 ， 首 先 对 传 入 的 resource 参 
数 做 封装 ， 目 的 是 考虑 到 Resource 可 能 存在 编码 要 求 的 情况 ， 其 次 ， 通 
过 SAX 读 取 XML 文 件 的 方式 来 准备 InputSource 对 象 ， 最 后 将 准备 的 数据 
通过 参数 传 入 真正 的 核心 处 理 部 分 doLoadBeanDefinitions(inputSource, 
encodedResource.getResource())。 
protected int doLoadBeanDefinitions(InputSource inputSource, 
Resource resource) 
throws BeanDefinitionStoreException { 
try { 
int validationMode = getValidationModeForResource(resource); 
Document doc = this.documentLoader.loadDocument( 
inputSource, getEntityResolver(), this.errorHandler, 
validationMode, 
isNamespaceA ware()); 
return registerBeanDefinitions(doc, resource); 
j 
catch (BeanDefinitionStoreException ex) { 
throw ex; 
} 
catch (SAXParseException ex) 1 
throw new 
XmlBeanDefinitionStoreException(resource.getDescription(), 
"Line " + ex.getLineNumber() + " in XML document from " + 
resource 


+" is invalid", ex); 


} 
catch (SAXException ex) { 
throw new 
XmlBeanDefinitionStoreException(resource.getDescription(), 
"XML document from " + resource + " is invalid", ex); 
j 
catch (ParserConfigurationException ex) ( 
throw new 
BeanDefinitionStoreException(resource.getDescription(), 
"Parser configuration exception parsing XML from " + resource, 
ex); 
j 
catch (IOException ex) 1 
throw new 
BeanDefinitionStoreException(resource.getDescription(), 
"IOException parsing XML document from " + resource, ex); 
j 
catch (Throwable ex) 1 
throw new BeanDefinitionStoreException(resource.getDescription(), 
"Unexpected exception parsing XML document from " + resource, 


ex); 


T1 


在 上 面 见 长 的 代码 中 假如 不 考虑 异常 类 的 代码 ， 
事 ， 这 三 件 事 的 每 一 件 都 必 不 可 少 。 

(1) 获取 对 XML 文件 的 验证 模式 。 

(2) 加 载 XML 文件 ， 并 得 到 对 应 的 Document。 
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(3) 根据 返回 的 Document 注 册 Bean 信 息 。 

这 3 个 步骤 文 撑 着 整个 Spring 容器 部 分 的 实现 基础 ， 尤 其 是 第 3 步 对 
配置 文件 的 解析 ， 逻 辑 非常 的 复杂 ， 那 么 我 们 先 从 获取 XML 文件 的 验 
证 模式 开始 讲 起 。 





2.6 获取 XML 的 验证 模式 


了 解 XML 文件 的 读者 都 应 该 知道 XML 文件 的 验证 模式 保证 了 XML 
文件 的 正确 性 ， 而 比较 常用 的 验证 模式 有 两 种 : DID 和 XSD。 它 们 之 间 
什么 区 别 呢 ? 


2.6.1 DTD EZ XSD|[* J 


DTD (Document Type Definition) 即 文档 类 型 定义 ， 是 一 种 XML 约 
束 模式 语言 ， 是 XML 文件 的 验证 机 制 ， 属 于 XML 文件 组 成 的 一 部 分 。 
DTD 是 一 种 保证 XML 文档 格式 正确 的 有 效 方法 ， 可 以 通过 比较 XML 文 
档 和 DTD 文 件 来 看 文档 是 否 符合 规范 ， 元 素 和 标签 使 用 是 否 正 确 。 一 个 
DID 文档 包含 : 元 素 的 定义 规则 ， 元 素 间 关系 的 定义 规则 ， 元 素 可 使 
用 的 属性 ， 可 使 用 的 实体 或 符号 规则 。 

要 使 用 DTD 验 证 模式 的 时 候 需 要 在 XML 文件 的 头 部 声明 ， 以 下 是 
在 Spring 中 使 用 DTD 声 明 方 式 的 代码 : 

<?xml version="1.0" encoding="UTF-8"?> 

<!DOCTYPE beans PUBLIC "-//Spring//DTD BEAN 2.0//EN" 
"http://www.Springframework. org/dtd/ 

















Spring-beans-2.0.dtd"> 

<beans> 

</beans> 

而 以 Spring 为 例 ， 具 体 的 Spring-beans-2.0.dtd 部 分 如 下 : 


<!ELEMENT beans ( 
description?, 
(import | alias | bean)* 

)> 

<!ATTLIST beans default-lazy-init (true | false) "false"> 

<!ATTLIST beans default-merge (true | false) "false"> 

<!ATTLIST beans default-autowire (no | byName | byType | constructor 
| autodetect) "no"> 

<!ATTLIST beans default-dependency-check (none | objects | simple | 
all) "none"> 

<!ATTLIST beans default-init-method CDATA #IMPLIED> 

<!ATTLIST beans default-destroy-method CDATA #IMPLIED> 

XML Schema 语言 就 是 XSD (XML Schemas Definition) . XML 
Schema 描述 了 XML 文档 的 结构 。 可 以 用 一 个 指定 的 XML Schema 来 验证 
东 个 XML 文档 ， 以 检查 该 XML 文档 是 售 符 合 其 要 求 。 文 档 设 计 者 可 以 
通过 XML Schema 指定 一 个 XML 文档 所 人 允许 的 结构 和 内 容 ， 并 可 据 此 检 
查 一 个 XML 文档 是 否 是 有 效 的 。XML Schema 本 身 是 一 个 XML 文档 ， 它 
符合 XML 语法 结构 。 可 以 用 通用 的 XML 解析 恬 解 析 它 。 

在 使 用 XML Schema 文档 对 XML 实例 文档 进行 检验 ， 除 了 要 声明 名 
称 空间 外 (xmlns= http://www.Springframework.org/schema/beans) ， 还 
必须 指定 该 名 称 空间 所 对 应 的 XML Schema 文档 的 存储 位 置 。 通 过 
schemaLocation 属 性 来 指定 名 称 空间 所 对 应 的 XML Schema 文档 的 存储 位 
置 ， 它 包含 两 个 部 分 ， 一 部 分 是 名 称 空间 的 URI， 男 一 部 分 就 是 该 名 称 
空间 所 标识 的 XML Schema 文 件 位 置 或 URL 地 址 


(xsi:schemaLocation="http://www.Springframework.org/schema/beans 




















http://www. Springframework.org/schema/beans/Spring-beans.xsd) . 


<?xml version="1.0" encoding="UTF-8"?> 
«beans xmlns="http://www.Springframework.org/schema/beans" 


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www.Springframework.org/schema/beans/Spring- 
beans.xsd"> 
</beans> 
Spring-beans-3.0.xsd 部 分 代码 如 下 : 
<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
<xsd:schema xmlns-"http://www.Springframework.org/schema/beans" 
xmlns:xsd="http://www.w3.org/2001/XML Schema" 
targetNamespace="http://www.Springframework.org/schema/beans"> 
<xsd:import namespace="http://www.w3.org/XML/1998/namespace"/> 
<xsd:annotation> 
«xsd:documentation» «![CDATA[ 
]]></xsd:documentation> 
</xsd:annotation> 
<!-- base types --> 
<xsd:complexType name="identifiedType" abstract="true"> 
<xsd:annotation> 
<xsd:documentation><![CDATA[ 
The unique identifier for a bean. The scope of the identifier 
is the enclosing bean factory. 


]]></xsd:documentation> 


</xsd:annotation> 
<xsd:attribute name="id" type="xsd:ID"> 
<xsd:annotation> 
<xsd:documentation><![CDATA[ 
The unique identifier for a bean. 
]]></xsd:documentation> 
</xsd:annotation> 
</xsd:attribute> 
</xsd:complexType> 


</xsd:schema> 


我 们 只 是 简单 地 介绍 一 下 XML 文件 的 验证 模式 的 相关 知识 ， 目 的 


在 于 让 读者 对 后 续 知 识 的 理解 能 有 连续 性 ， 如 果 对 XML 有 兴趣 的 读者 
可 以 进一步 查阅 相关 资料 。 





了 解 了 DID 与 XSD 的 区 别 后 我 们 再 去 分 析 Spring 中 对 于 验证 模式 的 


提取 就 更 容易 理解 了 。 通 过 之 前 的 分 析 我 们 锁定 了 Spring 通过 
getValidationModeForResource 方 法 来 获取 对 应 资源 的 的 验证 模式 。 





protected int getValidationModeForResource(Resource resource) { 
int validationModeToUse = getValidationMode(); 
/如 采 手 动 指定 了 验证 模式 则 使 用 指定 的 验证 模式 
if (validationModeToUse != VALIDATION_AUTO) { 
return validationModeToUse; 
} 
/如 采 未 指定 则 使 用 上 自动 检测 


int detectedMode = detect ValidationMode(resource); 


让 (detectedMode != VALIDATION_AUTO) { 
return detectedMode; 
} 
return VALIDATION_XSD; 
} 
方法 的 实现 其 实 还 是 很 简单 的 ， 无 非 是 如 果 设 定 了 验证 模式 则 使 用 
设 定 的 验证 模式 (可 以 通过 对 调用 XmlBeanDefinitionReader 中 的 
setValidationMode 方 法 进行 设 定 ) ， 人 否则 使 用 自动 检测 的 方式 。 而 上 自动 
检测 验证 模式 的 功能 是 在 函数 detectValidationMode 方 法 中 实现 的 ， 在 
detectValidationMode 函 数 中 又 将 自动 检测 验证 模式 的 工作 委托 给 了 专门 
处 理 类 XmlValidationMode Detector， 调 用 了 XmlValidationModeDetector 
的 validationModeDetector 方 法 ， 有 具体 代码 如 下 : 


protected int detectValidationMode(Resource resource) { 











if (resource.isOpen()) { 
throw new BeanDefinitionStoreException( 


"Passed-in Resource [" + resource + "] contains an open stream: " 


"cannot determine validation mode automatically. Either pass in 
a Resource " + 
"that is able to create fresh streams, or explicitly specify the 
validationMode " + 
"on your XmlBeanDefinitionReader instance."); 

} 

InputStream inputStream; 

try { 


inputStream = resource.getInputStream(); 


catch (IOException ex) { 
throw new BeanDefinitionStoreException( 


"Unable to determine validation mode for [" + resource + "J: 


cannot 
open InputStream. " + 
"Did you attempt to load directly from a SAX InputSource without 
specifying the " + 
"validationMode on your XmlBeanDefinitionReader instance?", 
ex); 
j 
try 1 


return 
this.validationModeDetector.detectV alidationMode(inputStream); 
j 
catch (IOException ex) 1 
throw new BeanDefinitionStoreException(" Unable to determine 
validation mode for [" + 
resource + "]: an error occurred whilst reading from the 


InputStream.", ex); 


j 
XmlValidationModeDetector.java 
public int detectValidationMode(InputStream inputStream) throws 
IOException 1 
BufferedReader reader = new BufferedReader(new 
InputStreamReader(inputStream)); 


try 1 


boolean isDtdValidated = false; 
String content; 
while ((content = reader.readLine()) != null) { 
content = consumeCommentTokens(content); 
/如 果 读 取 的 行 是 空 或 者 是 注释 则 略 过 
if (this.inComment || !StringUtils.hasText(content)) { 
continue; 
} 
if (hasDoctype(content)) { 
isDtdV alidated = true; 
break; 
j 
/ 读 取 到 < 开始 符号 ， 验 证 模式 一 定 会 在 开始 符号 之 前 
if (hasOpeningTag(content)) { 
break; 





} 
return (isDtdValidated ? VALIDATION_DTD : 
VALIDATION XSD); 
j 
catch (CharConversionException ex) 1 
// Choked on some character encoding... 
// Leave the decision up to the caller. 
return VALIDATION AUTO; 
j 
finally { 


reader.close(); 


} 
private boolean hasDoctype(String content) { 
return (content.indexOf(DOCTYPE) > -1); 
} 
只 要 我 们 理解 了 XSD 与 DTD 的 使 用 方法 ， 理 解 上 面 的 代码 应 该 不 会 
太 难 ，Spring 用 来 检测 验证 模式 的 办 法 就 是 判断 是 否 包 含 DOCTYPE， 
如 果 包 含 就 是 DTD， 和 否则 就 是 XSD。 


2.7 获取 Document 


经 过 了 验证 模式 准备 的 步骤 残 可 以 进行 Document 加 载 了 ， 同 样 
XmlBeanFactoryReader 类 对 于 文档 读 取 并 没有 杀 力 杀 为 ， 而 是 委托 给 了 
DocumentLoader 去 执行 ， 这 里 的 DocumentLoader 是 个 接口 ， 而 真正 调用 
的 是 DefaultDocumentLoader， 解 析 代 码 如 下 : 


DefaultDocumentLoader.java 








public Document loadDocument(InputSource inputSource, 

EntityResolver entityResolver, 

Exception { 

ErrorHandler errorHandler, int validation Mode, boolean 
namespaceA ware) throws 

DocumentBuilderFactory factory = 
createDocumentBuilderFactory(validationMode, 

namespaceA ware) 

if (logger.isDebugEnabled()) 1 

logger.debug(" Using JAXP provider [" + 

factory.getClass().getName() + "]"); 


} 

DocumentBuilder builder = createDocumentBuilder(factory, 
entityResolver, 

errorHandler); 

return builder.parse(inputSource); 

} 

对 于 这 部 分 代码 其 实 并 没有 太 多 可 以 描述 的 ， 因 为 通过 SAX 解 析 
XML 文档 的 套路 大 致 都 差不多 ，Spring 在 这 里 并 没有 什么 特殊 的 地 方 ， 
同样 首先 创建 DocumentBuilderFactory， 再 通过 DocumentBuilderFactory 
创建 DocumentBuilder， 进 而 解析 inputSource 来 返回 Document 对 象 。 对 此 
感 兴 趣 的 读者 可 以 在 网 上 获取 更 多 的 资料 。 这 里 有 必要 提 及 一 下 
EntityResolver， 对 于 参数 entityResolver， 传 入 的 是 通过 
getEntityResolver0O 函 数 获 取 的 返回 值 ， 如 下 代码 : 

protected EntityResolver getEntityResolver() { 





if (this.entityResolver == null) { 
// Determine default EntityResolver to use. 
ResourceLoader resourceLoader = getResourceLoader(); 
if (resourceLoader != null) { 
this.entityResolver = new 
ResourceEntityResolver(resourceLoader); 
} 
else { 
this.entityResolver = new DelegatingEntityResolver 
(getBeanClassLoader()); 
} 
} 


return this.entityResolver; 


} 
那么 ，EntityResolver 到 底 是 做 什么 用 的 呢 ? 


2.7.1 EntityResolver 用 法 


在 loadDocument 方 法 中 涉及 一 个 参数 EntityResolver， 何 为 
EntityResolver? 官网 这 样 解释 :如 果 SAX 应 用 程序 需要 实现 自 定义 处 理 
外 部 实体 ， 则 必须 实现 此 接口 并 使 用 setEntityResolver 方 法 问 SAX 驱动 
虱 注 册 一 个 实例 。 也 就 是 说 ， 对 于 解析 一 个 XML，SAX 前 先 读 取 该 
XML 文档 上 的 声明 ， 根 据 声 明 去 寻找 相应 的 DID 定义 ， 以 便 对 文档 进 
行 一 个 验证 。 默 认 的 寻找 规则 ， 即 通过 网 络 ( 实 现 上 就 是 声明 的 DTD 的 
URI 地 址 〉 来 下 载 相应 的 DID 声明， 并 进行 认证 。 下 载 的 过 程 是 一 个 漫 
长 的 过 程 ， 而 且 当 网 络 中 断 或 不 可 用 时 ， 这 里 会 报错 ， 就 是 因为 相应 的 
DTD 声 明 没 有 被 找到 的 原因 。 

EntityResolver 的 作用 是 项 目 本 喘 就 可 以 提供 一 个 如 何 寻找 DTD 声 明 
的 方法 ， 即 由 程序 来 实现 寻找 DID 声明 的 过 程 ， 比 如 我 们 将 DID 文件 放 
到 项 目 中 某 处 ， 在 实现 时 直接 将 此 文档 读 取 并 返回 给 SAX 即 可 。 这 样 就 
避免 了 通过 网 络 来 寻找 相应 的 声明 。 

首先 看 entityResolver 的 接口 方法 声明 : 

InputSource resolveEntity(String publicId, String systemId) 

这 里 ， 它 接收 两 个 参数 publicId 和 systemId， 并 返回 一 个 inputSource 
对 象 。 这 里 我 们 以 特定 配置 文件 来 进行 讲解 。 

(1) 如 采 我 们 在 解析 验证 模式 为 XSD 的 配置 文件 ， 代 码 如 下 : 


<?xml version="1.0" encoding="UTF-8"?> 














«beans xmlns="http://www.Springframework.org/schema/beans" 


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 


http://www.Springframework.org/schema/beans/Spring- 


beans.xsd"> 
</beans> 
读 取 到 以 下 两 个 参数 。 


publicId: null 

systemId: http://www.Springframework.org/schema/beans/Spring- 
beans.xsd 

(20 如 果 我 们 在 解析 验证 模式 为 DTD 的 配置 文件 ， 代 码 如 下 : 

<?xml version="1.0" encoding="UTF-8"?> 

<!DOCTYPE beans PUBLIC "-//Spring//DTD BEAN 2.0//EN" 
"http://www.Springframework. 

org/dtd/Spring-beans-2.0.dtd"> 


<beans> 
</beans> 
读 取 到 以 下 两 个 参数 。 


publicId: -//Spring//DTD BEAN 2.0//EN 

systemId: http://www.Springframework.org/dtd/Spring-beans-2.0.dtd 

之 前 已 经 提 到 过 ， 验 证 文件 默认 的 加 载 方式 是 通过 URL 进行 网 络 
下 载 获 取 ， 这 样 会 造成 延迟 ， 用 户 体 验 也 不 好 ， 一 般 的 做 法 都 是 将 验证 
文件 放置 在 自己 的 工程 里 ， 那 么 怎么 做 才能 将 这 个 URL 转 换 为 自己 工程 
里 对 应 的 地 址 文件 呢 ? 我 们 以 加 载 DTD 文 件 为 例 来 看 看 Spring 中 是 如 何 
实现 的 。 根 据 之 前 Spring 中 通过 getEntityResolver0 方 法 对 EntityResolver 
的 获取 ， 我 们 知道 ，Spring 中 使 用 DelegatingEntityResolver 类 为 
EntityResolver 的 实现 类 ，resolveEntity 实 现 方法 如 下 : 

DelegatingEntityResolver.java 


public InputSource resolveEntity(String publicId, String systemId) 
throws 
SA XException, IOException 1 
if (systemId != null) { 
if (systemId.endsWith(DTD SUFFIX)) { 
/如 果 是 dtd 从 这 里 解析 
return this.dtdResolver.resolveEntity(publicId, systemId); 
j 
else if (systemId.endsWith(XSD SUFFIX)) { 
/通过 调用 META-INF/Spring.schemas 解 析 


return this.schemaResolver.resolveEntity(publicId, SystemId ); 


} 
return null; 
} 
我 们 可 以 看 到 ， 对 不 同 的 验证 模式 ，Spring 使 用 了 不 同 的 解析 器 解 
析 。 这 里 简单 描述 一 下 原理 ， 比 如 加 载 DTD 类 型 的 BeansDtdResolver 的 
resolveEntity 是 直接 截取 systemId 最 后 的 xx.dtd 然 后 去 当前 路 径 下 寻找 ， 
而 加 载 XSD 类 型 的 PluggableSchemaResolver 类 的 resolveEntity 是 默认 到 
META-INEF/Spring.schemas 文 件 中 找到 systemid 所 对 应 的 XSD 文件 并 加 
载 。 
BeansDtdResolver.java 
public InputSource resolveEntity(String publicId, String systemId) 
throws IOException 1 
if (logger.isTraceEnabled()) 1 
logger.trace(" Trying to resolve XML entity with public ID [" + 
publicId + 


"] and system ID [" + SystemId + "]"); 
} 
// DTD_EXTENSION = ".dtd"; 
if (systemId != null && systemId.endsWith(DTD EXTENSION)) { 
int lastPathSeparator = systemlId.lastIndexOf("/"); 
for (String DID NAME : DID NAMES) { 
// DID NAMES = {"Spring-beans-2.0", "Spring-beans"}; 
int dtdNameStart = systemId.indexOf(DTD NAME); 
if (dtdNameStart > lastPathSeparator) { 
String dtdFile = systemId.substring(dtdNameStart); 
if (logger.isTraceEnabled()) 1 
logger.trace(" Trying to locate [" + dtdFile + "] in Spring 
jar"); 
j 
try { 
Resource resource = new ClassPathResource(dtdFile, 
getClass()); 
InputSource source - new 
InputSource(resource.getInputStream()); 
source.setPublicId(publicId); 
source.setSystemId(systemlId); 
if (logger.isDebugEnabled()) { 
logger.debug("Found beans DTD [" + SystemId + "] in 
classpath: " + dtdFile); 
} 


return source; 


catch (IOException ex) { 
if (logger.isDebugEnabled()) { 
logger.debug(" Could not resolve beans DTD [" + 
systemId 


* "]: not found in class path", ex); 


} 


return null; 


2.8 解 注册 BeanDefinitions 


当 把 文件 转换 为 Document 后 ， 接 下 来 的 提取 及 注册 bean 就 是 我 们 的 
重头 戏 。 继 续 上 面 的 分 析 ， 当 程序 已 经 拥有 XML 文档 文件 的 Document 
实例 对 象 时 ， 就 会 被 引入 下 面 这 个 方法 。 

XmlBeanDefinitionReader.java 

public int registerBeanDefinitions(Document doc, Resource resource) 
throws BeanDefinitionStore 

Exception 1 

/使 用 DefaultBeanDefinitionDocumentReader 实 例 化 
BeanDefinitionDocumentReader 
BeanDefinitionDocumentReader documentReader = 


createBeanDefinitionDocumentReader(); 
// 将 环境 变量 设置 其 中 


documentReader.setEnvironment(this.getEnvironment()); 
/在 实例 化 BeanDefinitionReader 时 候 会 将 BeanDefinitionRegistry 
传 入 ， 默 认 使 用 继承 目 
DefaultListableBeanFactory 的 子 类 
// 记 录 统 计 前 BeanDefinition 的 加 载 个 数 
int countBefore = getRegistry().getBeanDefinitionCount(); 
/加 载 及 注册 bean 
documentReader.registerBeanDefinitions(doc, 
createReaderContext(resource)); 
/记录 本 次 加 载 的 BeanDefinition 个 数 
return getRegistry().getBeanDefinitionCount() - countBefore; 
} 
其 中 的 参数 doc 是 通过 上 一 节 loadDocument 加 载 转换 出 来 的 。 在 
这 个 方法 中 很 好 地 应 用 了 面 癌 对 象 中 单一 职责 的 原则 ， 将 还 辑 处 理 委 托 
给 单一 的 类 进行 处 理 ， 而 这 个 逻辑 处 理 类 就 是 
BeanDefinitionDocumentReader. BeanDefinitionDocumentReaderzé — 4 
接口 ， 而 实例 化 的 工作 是 在 createBeanDefinitionDocumentReader() 中 完 
成 的 ， 而 通过 此 方法 ，BeanDefinitionDocumentReader 真 正 的 类 型 其 实 已 
经 是 DefaultBeanDefinitionDocumentReader 了 , HA 
DefaultBeanDefinition Document Reader 后 ， 发 现 这 个 方法 的 重要 目的 之 
一 就 是 提取 root， 以 便于 再 次 将 root 作为 参数 继续 BeanDefinition 的 注 
册 。 





public void registerBeanDefinitions(Document doc, XmlReaderContext 
readerContext) { 
this.readerContext = readerContext; 
logger.debug(" Loading bean definitions"); 


Element root = doc.getDocumentElement(); 


doRegisterBeanDefinitions(root); 


} 
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doRegisterBeanDefinitionsCroob， 至 少 我 们 在 这 个 方法 中 看 到 了 和 希望 。 

如 果 说 以 前 一 直 是 XML 加 载 解析 的 准备 阶段 ， 那 么 
doRegisterBeanDefinitions 算 是 真正 地 开始 进行 解析 了 ， 我 们 期 待 的 核心 
部 分 真正 开始 了 。 

protected void doRegisterBeanDefinitions(Element root) { 

/处 理 profile 属 性 
String profileSpec = root.getAttribute(PROFILE ATTRIBUTE); 
if (StringUtils.hasText(profileSpec)) { 


Assert.state(this.environment != null, "environment property must 





not be null"); 
String[] specifiedProfiles = 
StringUtils.tokenizeToStringArray(profileSpec, 


BeanDefinitionParserDelegate. MULTI VALUE ATTRIBUTE DELIMITEF 
if (!this.environment.acceptsProfiles(specifiedProfiles)) 1 


return; 


j 

/专门 处 理解 析 

BeanDefinitionParserDelegate parent = this.delegate; 
this.delegate = createHelper(readerContext, root, parent); 
/解析 前 处 理 ， 留 给 子 类 实现 

preProcess Xml(root); 


parseBeanDefinitions(root, this.delegate); 


/解析 后 处 理 ， 留 给 子 类 实现 
postProcessXml(root); 
this.delegate — parent; 
} 
通过 上 面 的 代码 我 们 看 到 了 处 理 流 程 ， 首 先是 对 profile 的 处 理 ， 然 
后 开始 进行 解析 ， 可 是 当 我 们 跟 进 preProcessXml(root) 或 者 
postProcessXml(root) 发 现代 人 码 是 空 的 ， 既 然 是 空 的 写 着 还 有 什么 用 呢 ? 
就 像 面 同 对 象 设计 方法 学 中 常 说 的 一 句 话 ， 一 个 类 要 么 是 面 同 继 承 的 设 
计 的 ， 要 么 就 用 final 修 饰 。 在 DefaultBeanDefinitionDocumentReader 中 并 
没有 用 final 修 饰 ， 所 以 它 是 面 癌 继承 而 设计 的 。 这 两 个 方法 正 是 为 子 类 
而 设计 的 ， 如 果 读 者 有 了 人 解 过 设计 模式 ， 可 以 很 快速 地 反映 出 这 是 模版 
方法 模式 ， 如 果 继 承 自 DefaultBeanDefinitionDocumentReader 的 子 类 需要 
在 Bean 解 析 前 后 做 一 些 处 理 的 话 ， 那 么 只 需要 重 写 这 两 个 方法 就 可 以 
i 


2.8.1 profile 属 性 的 使 用 


我 们 注意 到 在 注册 Bean 的 最 开始 是 对 PROFILE_ATTRIBUTE 属 性 的 
解析 ， 可 能 对 于 我 们 来 说 ，profile 属 性 并 不 是 很 常用 。 让 我 们 先 了 解 一 
下 这 个 属性 。 

分 析 profile 前 我 们 先 了 解 下 profile 的 用 法 ， 官 方 示例 代码 片段 如 
下 : 


«beans xmlns="http:/www.Springframework.org/schema/beans" 








xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmins:jdbc-" http://www. 

Springframework.org/schema/jdbc" 

xmins:jee-"http://www.Springframework.org/schema/jee" 


xsi:schemaLocation="..."> 


</beans> 
<beans profile="production"> 
</beans> 

</beans> 

集成 到 Web 环 境 中 时 ， 在 web.xml 中 加 入 以 下 代码 : 

<context-param> 

<param-name>Spring.profiles.active</param-name> 

<param-value>dev</param-value> 

</context-param> 

有 了 这 个 特性 我 们 就 可 以 同时 在 配置 文件 中 部 署 两 套 配 置 来 适用 于 
生产 环境 和 开发 环境 ， 这 样 可 以 方便 的 进行 切换 开发 、 部 署 环 境 ， 最 常 
用 的 就 是 更 换 不 同 的 数据 库 。 

了 解 了 profile 的 使 用 再 来 分 析 代 码 会 清晰 得 多 ， 首 先 程序 会 获取 
beans 节点 是 否定 义 了 profile 属性 ， 如 果 定 义 了 则 会 需要 到 环境 变量 中 
去 寻找 ， 所 以 这 里 首先 断言 environment 不 可 能 为 空 ， 因 为 profile 是 可 
以 同时 指定 多 个 的 ， 需 要 程序 对 其 拆 分 ， 并 解析 每 个 profile 是 都 符合 环 
境 变 量 中 所 定义 的 ， 不 定义 则 不 会 浪费 性 能 去 解析 。 


2.8.2 解析 并 注册 BeanDefinition 
处 理 了 profile Ja wt uH] WET XML 的 读 取 了 ， 跟 踩 代码 进入 


parseBeanDefinitions(root, this.delegate)。 











protected void parseBeanDefinitions(Element root， 


BeanDefinitionParserDelegate delegate) { 


/对 beans 的 处 理 
if (delegate.isDefaultNamespace(root)) { 
NodeList nl = root.getChildNodes(); 
for (int i = 0; i < nl.getLength(); i++) { 
Node node = nl.item(i); 
if (node instanceof Element) { 
Element ele = (Element) node; 
if (delegate.isDefaultNamespace(ele)) { 
/对 bean 的 处 理 
parseDefaultElement(ele, delegate); 
} 
else { 
/对 bean 的 处 理 


delegate.parseCustomElement(ele); 


} 


else { 
delegate.parseCustomElement(root); 


} 

上 面 的 代码 看 起 来 逻辑 还 是 蛋清 晰 的 ， 因 为 在 Spring 的 XML 配 置 里 
面 有 两 大 类 Bean 声 明 ， 一 个 是 默认 的 ， 如 : 

<bean id="test" class="test.TestBean"/> 

男 一 类 就 是 自 定 义 的 ， 如 : 


<tx:annotation-driven/> 


而 两 种 方式 的 读 取 及 解析 差别 是 非常 大 的 ， 如 有 果 采 用 Spring 默认 的 
配置 ，Spring 当 然 知道 该 怎么 做 ， 但 是 如 果 是 自 定义 的 ， 那 么 就 需要 用 
户 实现 一 些 接口 及 配置 了 。 对 于 根 节点 或 者 子 节 点 如 果 是 默认 命名 空间 
的 话 则 采用 parseDefaultElement 方法 进行 解析 ， 否 则 使 用 
delegate.parseCustomElement 方 法 对 自 定 义 命名 空间 进行 解析 。 而 判断 是 
否 默 认命 名 空间 还 是 自 定义 命名 空间 的 办 法 其 实 是 使 用 
node.getNamespaceURI() 获 取 命 名 空间 ， 并 与 Spring 中 国定 的 命名 空间 
http://www. Springframework.org/schema/beans 进行 比 对 。 如 果 一 致 则 认 
为 是 默认 ， 人 否则 惑 认 为 是 自 定 义 。 而 对 于 默认 标签 解析 与 自 定 义 标签 解 
析 我 们 将 会 在 下 一 章 中 进行 讨论 。 








第 3 章 ”默认 标签 的 解 
之 前 提 到 过 Spring 中 的 标签 包括 默认 标签 和 上 自 定 义 标签 两 种 ， 而 两 
iix 的 用 法 以 及 解析 方式 存在 着 很 大 的 不 同 ， 本 章节 重点 带领 读者 详 
田 分 析 默 认 标签 的 解析 过 程 。 
默认 标签 的 解析 是 在 parseDefaultElement 函 数 中 进行 的 ， 函 数 中 的 
功能 逻辑 一 目 了 然 ， 分 别 对 4 种 不 同 标签 〈import、alias、bean 和 beans ) 
做 了 不 同 的 处 理 。 


private void parseDefaultElement(Element ele, 








BeanDefinitionParserDelegate delegate) { 
/对 import 标 签 的 处 理 
if (delegate. nodeNameEquals(ele, IMPORT_ELEMENT)) { 
importBeanDefinitionResource(ele); 
} 
/对 alias 标 签 的 处 理 
else if (delegate.nodeNameEquals(ele, ALIAS_ELEMENT)) { 


processA liasRegistration(ele); 
} 
/对 bean 标 签 的 处 理 
else if (delegate.nodeNameEquals(ele, BEAN ELEMENT)) { 
processBeanDefinition(ele, delegate); 
j 
/对 beans 标 签 的 处 理 
else if (delegate.nodeNameEquals(ele, 
NESTED BEANS ELEMENT)) { 


doRegisterBeanDefinitions(ele); 


3.1 bean 标 签 的 解 注 


在 4 种 标签 的 解析 中 ， 对 bean 标签 的 解析 最 为 复杂 也 最 为 重要 ， 
所 以 我 们 从 此 标签 开始 深入 分 析 ， 如 果 能 理解 此 标签 的 解析 过 程 ， 其 他 
标签 的 解析 自然 会 迎刃而解 。 首 先 我 们 进入 函数 
processBeanDefinition(ele, delegate). 
protected void processBeanDefinition(Element ele, 
BeanDefinitionParserDelegate delegate) { 
BeanDefinitionHolder bdHolder = 
delegate.parseBeanDefinitionElement(ele); 
if (bdHolder != null) { 
bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, 
bdHolder); 
try { 


getRegistry()); 
BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, 
getReaderContext().&nbsp; } 
catch (BeanDefinitionStoreException ex) { 
getReaderContext().error(" Failed to register bean definition with 
name ”十 
bdHolder.getBeanName() + "", ele, ex); 
} 
getReaderContext().fireComponentRegistered(new 
BeanComponentDefinition(bdHolder)); 
} 
} 
乍 一 看 ， 似 乎 一 头 雾 水 ， 没 有 以 前 的 函数 那样 清晰 的 逻辑 。 大 致 的 
逻辑 总 结 如 下 。 

(1) 首先 委托 BeanDefinitionDelegate 类 的 
parseBeanDefinitionElement 方 法 进行 元 素 解 析 ， 返 回 
BeanDefinitionHolder 类 型 的 实例 bdHolder， 经 过 这 个 方法 后 ，bdHolder 
实例 已 经 包含 我 们 配置 文件 中 配置 的 各 种 属性 了 ， 例 如 class、name、 
id、alias 之 类 的 属性 。 

(2) 当 返 回 bdHolder 不 为 衬 的 情况 下 知 存 在 默认 标签 的 子 节 点 

下 再 有 自 定 义 属 性 ， 还 需要 再 次 对 自 定义 标签 进行 解析 。 

(3) MOM 需要 对 解析 后 的 bdHolder 进行 注册 ， 同 样 ， 注 
册 操 作 委 托 给 了 Bean DefinitionReaderUtils 的 registerBeanDefinition 方 
15s 








(4) 最 后 发 出 啊 应 事件 ， 通 知 想 关 的 监听 器 ， 这 个 bean 已 经 加 载 
完成 了 。 
配合 时 序 图 〈 如 图 3-1 所 示 ) ， 可 能 会 更 容易 理解 。 
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图 3-1 bean 标 签 的 解析 及 注册 时 序 图 


3.1.1 解 


BeanDefinition 


ontext XmlReaderContext 


下 面 我 们 就 针对 各 个 操作 做 具体 分 析 。 首 先 我 们 从 元 素 解 析 及 信息 
提取 开始 ， 也 就 是 BeanDefinitionHolder bdHolder = 
delegate.parseBeanDefinitionElement(ele), 3t ^BeanDefinition Delegate% 
的 parseBeanDefinitionElement 方 法 。 


BeanDefinitionDelegate.java 


public BeanDefinitionHolder parseBeanDefinitionElement(Element ele) 


return parseBeanDefinitionElement(ele, null); 


} 


public BeanDefinitionHolder parseBeanDefinitionElement(Element ele, 


BeanDefinition 


containingBean) { 


/解析 id 属性 
String id = ele.getAttribute(ID ATTRIBUTE); 
/解析 name 属 性 
String nameAttr = ele.getAttribute(NAME ATTRIBUTE); 
/分 割 name 属 性 
List<String> aliases = new ArrayList<String>(); 
if (StringUtils.hasLength(nameAttr)) { 
String[] nameArr = 
StringUtils.tokenizeToStringArray(nameAttr, MULTI_ 
VALUE_ATTRIBUTE_DELIMITERS); 
aliases.addAll(Arrays.asList(nameArr)); 
j 
String beanName - id; 
if (!StringUtils.hasText(beanName) && !aliases.isEmpty()) 1 
beanName - aliases.remove(0); 
if (logger.isDebugEnabled()) 1 
logger.debug("No XML 'id' specified - using "  beanName + 


"as bean name and " + aliases + " as aliases"); 


j 
if (containingBean == null) { 
checkNameUniqueness(beanName, aliases, ele); 
} 
AbstractBeanDefinition beanDefinition = 
parseBeanDefinitionElement(ele, beanName, 
containingBean); 


if (beanDefinition != null) { 


if (!StringUtils.hasText(beanName)) { 
try { 
/如 果 不 存 在 beanName 那 么 根据 Spring 中 提供 的 命名 规 
则 为 当前 bean 生 成 对 应 
的 beanName 
if (containingBean != null) { 
beanName = 
BeanDefinitionReaderUtils.generateBeanName( 
beanDefinition, this.readerContext.getRegistry(), true); 
} 
else { 
beanName = 
this.readerContext.generateBeanName(beanDefinition); 
String beanClassName = 
beanDefinition.getBeanClassName(); 
if (beanClassName != null && 
> beanClassName.length() && 
beanName.startsWith(beanClassName) && 


beanName.length() 
(beanClassName)) { 
Ithis.readerContext.getRegistry(). IsBeanNameInUse 
aliases.add(beanClassName); 
} 
} 


if (logger.isDebugEnabled()) { 
logger.debug("Neither XML 'id' nor name' specified - " + 


"using generated bean name [" + beanName + "]"); 


} 
catch (Exception ex) { 
error(ex.getMessage(), ele); 


return null; 


} 
String[] aliasesArray = StringUtils.toString Array(aliases); 
return new BeanDefinitionHolder(beanDefinition, beanName, 
aliasesArray); 
} 
return null; 

} 

以 上 便 是 对 默认 标签 解析 的 全 过 程 了 。 当 然 ， 对 Spring 的 解析 犹如 
洋葱 剥皮 一 样 ， 一 层 一 层 地 进行 ， 尺 管 现在 只 能 看 到 对 属性 id 以 及 name 
的 解析 ， 但 是 很 庆幸 ， 思 路 我 们 已 经 了 解 了 。 在 开始 对 属性 展开 全 面 解 
析 前 ，Spring 在 外 层 又 做 了 一 个 当前 层 的 功能 架构 ， 在 当前 层 完成 的 主 
要 工作 包括 如 下 内 容 。 

(1) 提取 元 素 中 的 id 以 及 name 属 性 。 
(2) 进一步 解析 其 他 所 有 属性 并 统一 封装 至 GenericBeanDefinition 
类 型 的 实例 中 。 
(3) 如果 检 测 到 bean 没 有 指定 beanName， 那 么 使 用 默认 规则 为 此 
Bean 生 成 beanName。 
(4) 将 获取 到 的 信息 封装 到 BeanDefinitionHolder 的 实例 中 。 
我 们 进一步 地 得 看 步骤 (20 中 对 标签 其 他 属性 的 解析 过 程 。 


public AbstractBeanDefinition parseBeanDefinitionElement( 











Element ele, String beanName, BeanDefinition containingBean) { 


this.parseState.push(new BeanEntry(beanName)); 
String className = null; 
/解析 class 属 性 
if (ele.hasAttribute(CLASS ATTRIBUTE)) { 
className = ele.getAttribute(CLASS_ATTRIBUTE).trim!(); 
} 
try { 
String parent = null; 
/解析 parent 属 性 
if (ele.hasAttribute(PARENT_ATTRIBUTE)) { 
parent = ele.getAttribut(PARENT ATTRIBUTE); 
} 
/创建 用 于 承载 属性 的 AbstractBeanDefinition 类 型 的 


GenericBeanDefinition 


AbstractBeanDefinition bd = createBeanDefinition(className, 


parent); 


bd); 


// 硬 编码 解析 默认 bean 的 各 种 属性 


parseBeanDefinitionAttributes(ele, beanName, containingBean, 


IT HX description 
ELEMENT); 


bd.setDescription(DomUtils.getChildElementValueByTagNamew(ele, 
DESCRIPTION 


/解析 元 数据 


parseMetaElements(ele, bd); 
/解析 lookup-method 属 性 


parseLookupOverrideSubElements(ele, bd.getMethodOverrides()); 
/解析 replaced-method 属 性 
parseReplacedMethodSubElements(ele, bd.getMethodOverrides()); 
/解析 构造 函数 参数 
parseConstructorArgElements(ele, bd); 
/解析 property 子 元 素 
parsePropertyElements(ele, bd); 
/解析 qualifier 子 元 素 
parseQualifierElements(ele, bd); 
bd.setResource(this.readerContext.getResource()); 
bd.setSource(extractSource(ele)); 
return bd; 
} 
catch (ClassNotFoundException ex) { 
error(""Bean class [" + className + "] not found", ele, ex); 
} 
catch (NoClassDefFoundError err) { 
error("Class that bean class [" + className + "| depends on not 
found", ele, err); 
} 
catch (Throwable ex) { 
error("Unexpected failure during bean definition parsing", ele, ex); 
} 
finally { 
this.parseState.pop(); 
} 


return null; 


} 
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兴奋 的 心情 。 接 下 来 ， 我 们 继续 一 些 复杂 标签 属性 的 解析 。 

1. 创建 用 于 属性 承载 的 BeanDefinition 

BeanDefinition 是 一 个 接口 ， 在 Spring 中 存在 三 种 实现 : 
RootBeanDefinition、ChildBean Definition 以 及 GenericBeanDefinition 。 
三 种 实现 均 继 承 了 AbstractBeanDefiniton ， 其 中 BeanDefinition 是 配置 文 
件 <bean> 元 素 标签 在 容器 中 的 内 部 表示 形式 。<bean> 元 素 标签 拥有 
class、scope、lazy-init 等 配置 属性 ，BeanDefinition 则 提供 了 相应 的 
beanClass、scope、lazyInit 属 性 ，BeanDefinition 和 <bean> 中 的 属性 是 一 
一 对 应 的 。 其 中 RootBeanDefinition 是 最 常用 的 实现 类 ， 它 对 应 一 般 性 的 
<bean> 元 素 标签 ，GenericBeanDefinition 是 自 2.5 版 本 以 后 新 加 入 的 bean 
文件 配置 属性 定义 类 ， 是 一 站 式 服务 类 。 

在 配置 文件 中 可 以 定义 父 <bean> 和 子 <bean>， 父 <bean> 用 
RootBeanDefinition 表 示 ， 而 子 <bean> 用 ChildBeanDefiniton 表 示 ， 而 没 
有 父 <bean> 的 <bean> 束 使 用 RootBeanDefinition 表 示 。 
AbstractBeanDefinition 对 两 者 共同 的 类 信息 进行 抽象 。 

Spring 通过 BeanDefinition 将 配置 文件 中 的 <bean> 配 置信 息 转 换 为 容 
器 的 内 部 表示 ， 并 将 这 些 BeanDefiniton 注 册 到 BeanDefinitonRegistry 中 . 
Spring 容器 的 BeanDefinitionRegistry 就 像 是 Spring 配置 信息 的 内 存 数 据 
库 ， 主 要 是 以 map 的 形式 保存 ， 后 续 操 作 直 接 从 BeanDefinition Registry 
中 读 取 配置 信息 。 它 们 之 间 的 关系 如 图 3-2 所 示 。 
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图 3-2 BeanDefinition 及 其 实现 类 


由 此 可 知 ， 要 解析 属性 首先 要 创建 用 于 承载 属性 的 实例 ， 也 就 是 创 
建 GenericBeanDefinition 类 型 的 实例 。 而 代码 
createBeanDefinition(className, parent) 的 作用 就 是 实现 此 功能 。 
protected AbstractBeanDefinition createBeanDefinition(String 
className, String parentName) 
throws ClassNotFoundException { 
return BeanDefinitionReaderUtils.createBeanDefinition( 
parentName, className, this.readerContext.getBeanClassLoader()); 
} 
BeanDefinitionReaderUtils.java 
public static AbstractBeanDefinition createBeanDefinition( 
String parentName, String className, ClassLoader classLoader) throws 
ClassNotFoundException { 


GenericBeanDefinition bd = new GenericBeanDefinition(); 


/parentName 可 能 为 空 
bd.setParentName(parentName); 
if (className != null) { 
if (classLoader != null) { 
/如 果 classLoader 不 为 衬 ， 则 使 用 以 传 入 的 classLoader 同 一 虚拟 
机 加 载 类 对 象 ， 否 则 只 是 
记录 className 
bd.setBeanClass(ClassUtils.forName(className, classLoader)); 
} 


else { 


bd.setBeanClassName(className); 


} 
return bd; 
} 
2. 解析 各 种 属性 
当 我 们 创建 了 bean 信 息 的 承载 实例 后 ， 便 可 以 进行 bean 信 息 的 各 种 
属性 解析 了 ， 首 先 我 们 进入 parseBeanDefinitionAttributes 方 法 。 
parseBeanDefinitionAttributes 方 法 是 对 element 所 有 元 素 属性 进行 解析 : 
public AbstractBeanDefinition parseBeanDefinitionAttributes(Element 
ele, String beanName, 
BeanDefinition containingBean, AbstractBeanDefinition bd) { 
/解析 scope 属 性 
if (ele.hasAttribute(SCOPE_ATTRIBUTE)) { 
// Spring 2.x "scope" attribute 
bd.setScope(ele.getAttribute(SCOPE ATTRIBUTE)); 
if (ele.hasAttribute(SINGLETON ATTRIBUTE)) { 


/scope 与 singleton 两 个 属性 只 能 指定 其 中 之 一 ， 不 可 以 同时 出 
现 ， 否 则 Spring 将 会 报 出 异常 
error("Specify either 'scope' or 'singleton', not both", ele); 
j 
j 
/解析 singleton 属 性 
else if (ele.hasAttribute(SINGLETON_ATTRIBUTE)) { 
// Spring 1.x "singleton" attribute 


bd.setScope(TRUE VALUE.equals(ele.getAttribute(SINGLETON ATTRIB! 
? 
BeanDefinition.SCOPE SINGLETON : 
BeanDefinition.SCOPE PROTOTYPE); 
j 
else if (containingBean !- null) { 
// Take default from containing bean in case of an inner bean 
definition. 
// 在 艇 入 beanDifinition 情 况 下 且 没 有 单独 指定 scope 属 性 则 使 用 父 
类 默认 的 属性 
bd.setScope(containingBean.getScope()); 
} 
/解析 abstract 属 性 
if (ele.hasAttribute( ABSTRACT ATTRIBUTE)) { 


bd.setAbstract( TRUE. VALUE.equals(ele.getAttribute(KABSTRACT ATTRII 
j 
/解析 lazy-init 属 性 


String lazyInit = ele.getAttribute(LAZY_INIT_ATTRIBUTE); 
if (DEFAULT_VALUE.equals(lazyInit)) { 
lazyInit = this.defaults.getLazyInit(); 
} 
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bd.setLazyInit(TRUE_VALUE.equals(lazyInit)); 
/解析 autowire 属 性 
String autowire = ele.getAttribute AUTOWIRE_ATTRIBUTE); 
bd.setAutowireMode(getAutowireMode(autowire)); 
/解析 dependency-check 属 性 
String dependencyCheck = 
ele.getAttribute(DEPENDENCY_CHECK_ATTRIBUTE); 
bd.setDependencyCheck(getDependencyCheck(dependencyCheck)); 
// 解 析 depends-on 属 性 
if (ele.hasAttribute(DEPENDS_ON_ATTRIBUTE)) { 
String dependsOn = ele.getAttribute(DEPENDS_ON_ATTRIBUTE); 
bd.setDependsOn(StringUtils.tokenizeToStringArray(dependsOn, 
MULTI VALUE . 
ATTRIBUTE DELIMITERS)); 
j 
/解析 autowire-candidate 属 性 
String autowireCandidate = 
ele.getAttribute(AUTOWIRE CANDIDATE ATTRIBUTE); 
if ("".equals(autowireCandidate) || 
DEFAULT VALUFE.equals(autowireCandidate)) 1 
String candidatePattern = this.defaults.getAutowireCandidates(); 
if (candidatePattern != null) { 


String[] patterns = StringUtils.commaDelimitedListToStringArray 


(candidatePattern); 


bd.setAutowireCandidate(PatternMatchUtils.simpleMatch(patterns, 
beanName)); 
} 
} 


else { 


bd.setAutowireCandidate(TRUE_VALUE.equals(autowireCandidate)); 
} 
/解析 primary 属 性 
if (ele.hasAttribut( PRIMARY ATTRIBUTE)) { 


bd.setPrimary(TRUE VALUE.equals(ele.getAttribute(PRIMARY ATTRIBL 
j 
/解析 init-method 属 性 
if (ele.hasAttribute(INIT METHOD ATTRIBUTE)) { 
String initMethodName = 
ele.getAttribut(INIT METHOD ATTRIBUTE); 
if (!"".equals(initMethodName)) { 
bd.setInitMethodName(initMethodName); 


} 
else { 
if (this.defaults.getInitMethod() != null) { 
bd.setInitMethodName(this.defaults.getInitMethod()); 


bd.setEnforceInitMethod(false); 


} 
/解析 destroy-method 属 性 
if (ele.hasAttribut( DESTROY METHOD ATTRIBUTE)) { 
String destroyMethodName = 
ele.getAttribut(DESTROY METHOD ATTRIBUTE); 
if (!"".equals(destroyMethodName)) { 
bd.setDestroyMethodName(destroyMethodName); 


} 
else { 
if (this.defaults.getDestroyMethod() != null) { 
bd.setDestroyMethodName(this.defaults.getDestroyMethod()); 
bd.setEnforceDestroyMethod(false); 


} 
/解析 factory-method 属 性 
if (ele.hasAttribut(FACTORY METHOD ATTRIBUTE)) { 


bd.setFactoryMethodName(ele.getAttribute(FACTORY METHOD ATTRIP 
} 
/解析 factory-bean 属 性 
if (ele.hasAttribut(FACTORY BEAN ATTRIBUTE)) { 


bd.setFactoryBeanName(ele.getAttribute(FACTORY BEAN ATTRIBUTE) 
} 


return bd; 

} 

我 们 可 以 清楚 地 看 到 Spring 完成 了 对 所 有 bean 属 性 的 解析 ， 这 些 属 
性 中 有 很 多 是 我 们 经 常 使 用 的 ， 同 时 我 相信 也 一 定 会 有 或 多 或 少 的 属性 
是 读者 不 熟悉 或 者 是 没有 使 用 过 的 ， 有 兴趣 的 读者 可 以 查阅 相关 资料 进 
一 步 了 解 每 个 属性 。 

3. 解析 子 元 素 meta 

在 开始 解析 元 数据 的 分 析 前 ， 我 们 先 回 顾 下 元 数据 meta 属 性 的 使 











<bean id="myTestBean" class="bean.MyTestBean"> 
«meta key="testStr" value="aaaaaaaa"/> 
</bean> 
这 段 代码 并 不 会 体现 在 MyTestBean 的 属性 当中 ， 而 是 一 个 额外 的 
声明 ， 当 需要 使 用 里 面 的 信息 的 时 候 可 以 通过 BeanDefinition 的 
getAttribute(key) 方 法 进行 获取 。 
对 meta 属 性 的 解析 代码 如 下 : 
public void parseMetaElements(Element ele, 
BeanMetadataAttributeAccessor attributeAccessor) { 
/获取 当前 节点 的 所 有 子 元 素 
NodeList nl = ele.getChildNodes(); 
for (int i = 0; i < nl.getLength(); i++) { 





Node node - nl.item(i); 
/提取 meta 
if (isCandidateElement(node) && nodeNameEquals(node, 
META, ELEMENT)) { 
Element metaElement = (Element) node; 
String key = metaElement.getAttribute(KEY ATTRIBUTE); 


String value = 
metaElement.getAttribute(VALUE_ATTRIBUTE); 
/使 用 key、value 构 造 BeanMetadataAttribute 
BeanMetadataAttribute attribute = new 
BeanMetadataAttribute(key, value); 
attribute.setSource(extractSource(metaElement)); 
/记录 信息 
attributeAccessor.addMetadataA ttribute(attribute); 


} 

4. 解析 子 元 素 lookup-method 

同样 ， 子 元 素 lookup-method 似乎 并 不 是 很 常用 ， 但 是 在 某 些 时 候 
它 的 确 是 非常 有 用 的 属性 ， 通 常 我 们 称 它 为 获取 器 注入 。 引 用 《Spring 
in Action》 中 的 一 句 话 : 获取 器 注入 是 一 种 特殊 的 方法 注入 ， 它 是 把 一 
个 方法 声明 为 返回 某 种 类 型 的 bean， 但 实际 要 返回 的 bean 是 在 配置 文 
件 里 面 配置 的 ， 此 方法 可 用 在 设计 有 些 可 搬 拔 的 功能 上 ， 解 除 程序 依 
赖 。 我 们 看 看 具体 的 应 用 。 

(1) 首先 我 们 创建 一 个 父 类 。 


package test.lookup.bean; 














public class User { 
public void showMe(){ 


System.out.printin("i am user"); 


} 
(2) BE FASE tishowMe Vik. 


package test.lookup.bean; 


public class Teacher extends User{ 
public void showMe(){ 


System.out.println("i am Teacher"); 


j 
(3) 创建 调用 方法 。 
public abstract class GetBeanTest { 
public void showMe(){ 
this.getBean().showMe(); 
} 
public abstract User getBean(); 
} 
(4) 创建 测试 方法 。 
package test.lookup; 
import org.Springframework.context.A pplicationContext; 
import 
org.Springframework.context.support.ClassPathXmlApplicationContext; 
import test.lookup.app.GetBeanTest; 
public class Main { 
public static void main(String[] args) { 
ApplicationContext bf = 
new 
ClassPathXmlApplicationContext("test/lookup/lookupTest.xml"); 
GetBeanTest test=(GetBeanTest) bf.getBean("getBeanTest"); 
test.showMe(); 





到 现在 为 止 ， 除 了 配置 文件 外 ， 整 个 测试 方法 就 完成 了 ， 如 果 之 前 
没有 接触 过 获取 需 注 入 的 读者 们 可 能 会 有 疑问 : 抽象 方法 还 没有 被 实 
现 ， 怎 么 可 以 直接 调用 呢 ? 答案 就 在 Spring 为 我 们 提供 的 获取 器 中 ， 我 
们 看 看 配置 文件 是 怎么 配置 的 。 


<?xml version="1.0" encoding="UTF-8"?> 











«beans xmlIns="http://www.Springframework.org/schema/beans" 


xmins:xsi-"http://www.w3.0rg/2001/XML Schema-instance" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www. Springframework. 
org/schema/beans/Spring-beans.xsd"> 
<bean id-"getBeanTest" class="test.lookup.app.GetBeanTest"> 
<lookup-method name="getBean" bean="teacher"/> 
</bean> 
<bean id="teacher" class="test.lookup.bean.Teacher"/> 
</beans> 
在 配置 文件 中 ， 我 们 看 到 了 源码 解析 中 提 到 的 lookup-method 子 元 
素 ， 这 个 配置 完成 的 功能 是 动态 地 将 teacher 所 代表 的 bean 作 为 getBean 的 
返回 值 ， 运 行 测试 方法 我 们 会 看 到 控制 台 上 的 输出 : 
i am Teacher 
当 我 们 的 业务 变更 或 者 在 其 他 情况 下 ，teacher 里 面 的 业务 逻辑 已 经 
不 再 符合 我 们 的 业务 要 求 ， 需 要 进行 殖 换 怎么 办 呢 ? 这 是 我 们 需要 增加 
新 的 逻辑 类 : 
package test.lookup.bean; 
public class Student extends User { 
public void showMe(){ 


System.out.println("i am student"); 


} 

同时 修改 配置 文件 : 

<?xml version="1.0" encoding="UTF-8"?> 

«beans xmlns="http:/www.Springframework.org/schema/beans" 


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www.Springframework. 
org/schema/beans/Spring-beans.xsd"> 
<bean id="getBeanTest" class="test.lookup.app.GetBeanTest"> 
<lookup-method name="getBean" bean="student"/> 
</bean> 
<bean id="teacher" class="test.lookup.bean. Teacher"/> 
<bean id="student" class="test.lookup.bean.Student"/> 
</beans> 
再 次 运行 测试 类 ， 你 会 发 现 不 一 样 的 结 
i am Student 
至 此 ， 我 们 已 经 初步 了 解 了 lookup-method 子 元 素 所 提供 的 大 致 功 
相信 这 时 再 次 去 看 它 的 属性 提取 源码 会 觉得 更 有 和 针对 性 。 


public void parseLookupOverrideSubElements(Element beanEle, 














amp 
CC 


MethodOverrides overrides) { 
NodeList nl = beanEle.getChildNodes(); 
for (int i = 0; i < nl.getLength(); i++) { 
Node node = nl.item(i); 


/ 仅 当 在 Spring 默认 bean 的 子 元 素 下 且 为 <lookup-method 时 有 


METHOD ELEMENT)) { 
if (isCandidateElement(node) && nodeNameEquals(node, 
LOOKUP. 
Element ele = (Element) node; 
/获取 要 修饰 的 方法 
String methodName = ele.getAttribute(NAME ATTRIBUTE); 
/获取 配置 返回 的 bean 
String beanRef = ele.getAttribute(BEAN_ELEMENT); 
LookupOverride override = new LookupOverride(methodName, 
beanRef); 
override.setSource(extractSource(ele)); 


overrides.addOverride(override); 


} 

上 面 的 代码 很 眼熟 ， 似 乎 与 parseMetaElements 的 代码 大 同 小 异 ， 最 
大 的 区 别 就 是 在 if 判 断 中 的 节点 名 称 在 这 里 被 修改 为 
LOOKUP_METHOD_ELEMENT。 还 有 ， 在 数据 存储 上 面 通过 使 用 
LookupOverride 类 型 的 实体 类 来 进行 数据 承载 并 记录 在 
AbstractBeanDefinition 中 的 methodOverrides 属 性 中 。 

5. 解析 子 元 素 replaced-method 

这 个 方法 主要 是 对 bean 中 replaced-method 子 元 素 的 提取 ， 在 开始 提 
取 分 析 之 前 我 们 还 是 预先 介绍 下 这 个 元 素 的 用 法 。 

TRS: 可 以 在 运行 时 用 新 的 方法 蔡 换 现 有 的 方法 。 与 之 前 的 
look-up 不 同 的 是 ， replaced-method 不 但 可 以 动态 地 蔡 换 返回 实体 
bean， 而 且 还 能 动态 地 更 改 原 有 方法 的 逻辑 。 我 们 来 看 看 使 用 示例 。 

(1) 在 changeMe 中 完成 某 个 业务 逻辑 。 

















public class TestChangeMethod { 
public void changeMe(){ 
System.out.printIn("changeMe"); 


} 
(20 在 运营 一 段 时 间 后 需要 改变 原 有 的 业务 逻辑 。 
public class TestMethodReplacer implements MethodReplacer{ 
@Override 
public Object reimplement(Object obj, Method method, Object[] 





args)throws Throwable { 
System.out.printin(" 我 苦 换 了 原 有 的 方法 "); 


return null; 


} 
(3) 使 将 换 后 的 类 生效 。 
<?xml version="1.0" encoding="UTF-8"?> 
«beans xmlns="http://www.Springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www.Springframework. 
org/schema/beans/Spring-beans.xsd"> 
<bean id="testChangeMethod" 
class="test.replacemethod.TestChangeMethod"> 
<replaced-method name="changeMe" replacer="replacer"/> 
</bean> 
<bean id="replacer" class="test.replacemethod.TestMethodReplacer"/> 


</beans> 


(4) 测试 。 
public static void main(String[] args) { 
ApplicationContext bf = 
new 
ClassPathXmlApplicationContext( test/replacemethod/replaceMethodTest.xrr 
TestChangeMethod test=(TestChangeMethod) 
bf.getBean("testChangeMethod"); 
test.changeMe(); 
} 
好 了 ， 运 行 测试 类 就 可 以 看 到 预期 的 结果 了 ， 控 制 台 成 功 打 印 
出 “我 苦 换 了 原 有 的 方法 ”， 也 就 是 说 我 们 做 到 了 动态 普 换 原 有 方法 ， 知 
道 了 这 个 元 素 的 用 法 ， 我 们 再 次 来 看 元 素 的 提取 过 程 : 
public void parseReplacedMethodSubElements(Element beanEle, 
MethodOverrides overrides) { 
NodeList nl = beanEle.getChildNodes(); 
for (int i = 0; i < nl.getLength(); i++) { 
Node node = nl.item(i); 


/ 仅 当 在 Spring 默认 bean 的 子 元 素 下 且 为 <replaced-method 时 有 


ELEMENT)) { 
if (isCandidateElement(node) && nodeNameEquals(node, 
REPLACED METHOD 
Element replacedMethodEle = (Element) node; 
eR BS PRAIA 方法 
String name = 
replacedMethodEle.getAttribute(NAME ATTRIBUTE); 
IHE BOSE SEIS S PI] T PRT YZ 


String callback = 
replacedMethodEle.getAttribute(REPLACER, ATTRIBUTE); 
ReplaceOverride replaceOverride = new 
ReplaceOverride(name, callback); 
List<Element> argTypeEles = 
DomUtils.getChildElementsByTagName 
(replacedMethodEle, ARG. TYPE ELEMENT); 
for (Element argTypeEle : argTypeEles) 1 
/记录 参数 
String match = argTypeEle.getAttribute 
(ARG TYPE MATCH, ATTRIBUTE); 
match - (StringUtils.hasText(match) ? match : 
DomUtils.getTextValue 
(argT'ypeEle)); 
if (StringUtils.hasText(match)) { 
replaceOverride.addTypeldentifier(match); 


} 
replaceOverride.setSource(extractSource(replacedMethodEle)); 


overrides.addOverride(replaceOverride); 


} 

我 们 可 以 看 到 无 论 是 look-up 还 是 replaced-method 都 是 构造 了 一 个 
MethodOverride， 并 最 终 记 录 在 了 AbstractBeanDefinition 中 的 
methodOverrides 属 性 中 。 而 这 个 属性 如 何 使 用 以 完成 它 所 提供 的 功能 我 
们 会 在 后 续 的 章节 进行 详细 地 介绍 。 





6. 解析 子 元 素 constructor-arg 
对 构造 函数 的 解析 是 非常 第 用 的 ， 同 时 也 是 非常 复杂 的 ， 也 相信 大 
家 对 构造 函数 的 配置 都 不 陌生 ， 举 个 简单 的 小 例子 : 
<beans> 
<!-- 默认 的 情况 下 是 按照 参数 的 顺序 注入 ， 当 指定 index 索 引 后 就 可 
以 改变 注入 参数 的 顺序 --> 
<bean id="helloBean" class="com.HelloBean"> 
<constructor-arg index="0"> 
«value» (£</value> 
</constructor-arg> 
<constructor-arg index="1"> 
<value> 你 好 </value> 
</constructor-arg> 
</bean> 
</beans> 
上 面 的 配置 是 Spring 构 造 函 数 配置 中 最 基础 的 配置 ， 实 现 的 功能 就 
是 对 HelloBean 目 动 寻 找 对 应 的 构造 函数 ， 并 在 初始 化 的 时 候 将 设置 的 
参数 传 入 进去 。 那 么 让 我 们 来 看 看 具体 的 XML 解析 过 程 。 
对 于 constructor-arg 子 元 素 的 解析 ，Spring 是 通过 
parseConstructorArgElements 函 数 来 实现 的 ， 有 共 体 的 代码 如 下 : 
public void parseConstructorArgElements(Element beanEle, 
BeanDefinition bd) { 
NodeList nl = beanEle.getChildNodes(); 
for (int i = 0; i < nl.getLength(); i++) { 


Node node = nl.item(i); 





if (isCandidateElement(node) && nodeNameEquals(node, 
CONSTRUCTOR_ARG_ELEMENT)) { 
/解析 constructor-arg 
parseConstructorArgElement((Element) node, bd); 


} 
XSI ERATE RSE, PAT oR, (RUE ERUNT 
有 constructor-arg， 然 后 进行 解析 ， 但 是 具体 的 解析 却 被 放置 在 了 另 个 函 
数 parseConstructorArgElement 中 ， 有 具体 代码 如 下 : 
public void parseConstructorArgElement(Element ele, BeanDefinition 
bd) { 
/提取 index 属 性 
String indexAttr = ele.getAttribute(—INDEX_ATTRIBUTE); 
/提取 type 属 性 
String typeAttr = ele.getAttribute(TYPE_ATTRIBUTE); 
/提取 name 属 性 
String nameAttr = ele.getAttribute(NAME ATTRIBUTE); 
if (StringUtils.hasLength(indexAttr)) { 
try 1 
int index = Integer.parseInt(indexA ttr); 
if (index < 0) 1 
error("'index' cannot be lower than 0", ele); 
jelse 1 
try { 
this.parseState.push(new 


ConstructorArgumentEntry(index)); 


fee AT ele xt NL AY Je VE TC 38 
Object value = parsePropertyValue(ele, bd, null); 
ConstructorArgumentValues. ValueHolder valueHolder = 
new 
ConstructorArgumentV alues. V alueHolder(value); 
if (StringUtils.hasLength(typeAttr)) { 
valueHolder.set l'ype(typeA ttr); 
j 
if (StringUtils.hasLength(nameAttr)) ( 
valueHolder.setName(nameA ttr); 
j 
valueHolder.setSource(extractSource(ele)); 
/不 允许 重复 指定 相同 参数 
if (bd.getConstructorArgumentValues(). 
hasIndexedArgumentValue 
(index)) { 
error("Ambiguous constructor-arg entries for index " + 
index, ele); 
jelse 1 
(index, valueHolder); 
bd.getConstructorArgumentV alues(). 
AddIndexedArgumentValue 
j 
finally 1 
this.parseState.pop(); 


}catch (NumberFormatException ex) { 
error(" Attribute 'index' of tag 'constructor-arg' must be an 
integer", ele); 
j 
jelse 1 
// 没 有 index 属 性 则 忽略 去 属性 ， 自 动 寻找 
try { 
this.parseState.push(new ConstructorArgumentEntry()); 
Object value = parsePropertyValue(ele, bd, null); 
ConstructorArgumentValues. ValueHolder valueHolder = new 
Constructor 
ArgumentValues. ValueHolder(value); 
if (StringUtils.hasLength(typeAttr)) { 
valueHolder.setType(typeAttr); 
} 
if (StringUtils.hasLength(nameAttr)) { 
valueHolder.setName(nameAttr); 
} 


valueHolder.setSource(extractSource(ele)); 


bd.getConstructorArgumentV alues().addGenericArgumentV alue(valueHolder 


} 
finally { 
this.parseState.pop(); 





上 面 一 段 看 似 复杂 的 代码 让 很 多 人 失去 了 耐心 ， 但 是 ， 涉 及 的 逻辑 
其 实 并 不 复杂 ， 首 先是 提取 constructor-arg 上 必要 的 属性 〈index、type、 
name) 。 

如 果 配 置 中 指定 了 index 属 性 ， 那 么 操作 步骤 如 下 。 

(1) 解析 constructor-arg 的 子 元 素 。 

(2) 使 用 ConstructorArgumentValues.ValueHolder 类 型 来 封装 解析 
出 来 的 元 素 。 

(3) 将 type、name 和 index 属 性 一 并 封装 在 
ConstructorArgumentValues.ValueHolder 类 型 中 并 添加 至 当前 
BeanDefinition 和 的 constructorArgumentValues 的 indexedArgumentValues 属 
PEP 

如 有 果 没 有 指定 index 属 性 ， 那 么 操作 步骤 如 下 。 

(1) 解析 constructor-arg 的 子 元 素 。 

(2) 使 用 ConstructorArgumentValues.ValueHolder 类 型 来 封装 解析 
出 来 的 元 素 。 

(3) 将 type、name 和 index 属 性 一 并 封装 在 
ConstructorArgumentValues.ValueHolder 类 型 中 并 添加 至 当前 
BeanDefinition 的 constructorArgumentValues 的 genericArgumentValues 属 
PEP 

可 以 看 到 ， 对 于 是 否 制定 imdex 属 性 来 讲 ，Spring 的 处 理 流 程 是 不 同 
的 ， 关 键 在 于 属性 信息 被 保存 的 位 置 。 

那么 了 解 了 整个 流程 后 ， 我 们 尝试 着 进一步 了 解 解析 构造 函数 配置 
中 子 元 素 的 过 程 ， 进 入 parsePropertyValue: 

public Object parsePropertyValue(Element ele, BeanDefinition bd, 








String propertyName) { 


String elementName = (propertyName != null)? 


Tr 


"<property> element for property " + propertyName + """ ; 


"<constructor-arg> element"; 
/一 个 属性 只 能 对 应 一 种 类 型 : ref. value. list% 
NodeList nl = ele.getChildNodes(); 
Element subElement = null; 
for (int i = 0; i < nl.getLength(); i++) { 
Node node = nl.item(i); 
/对 应 description 或 者 meta 不 处 理 
if (node instanceof Element && !nodeNameEquals(node, 
DESCRIPTION_ELEMENT) && 
InodeNameEquals(node, META_ELEMENT)) { 
if (subElement != null) f 
error(elementName + " must not contain more than one sub- 
element", ele); 
j 
else { 
subElement = (Element) node; 


j 
/解析 constructor-arg 上 的 ref 属 性 

boolean hasRefAttribute = ele.hasAttribute(REF_ATTRIBUTE); 
/解析 constructor-arg 上 的 value 属 性 

boolean hasValueAttribute = 

ele.hasAttribute(VALUE_ATTRIBUTE); 
if ((hasRefAttribute && hasValueAttribute) || 
((hasRefAttribute || hasValueAttribute) && subElement != null)) { 


/* 


* 在 constructor-arg 上 不 存在 : 

* ] 、 同 时 既 有 ref 属 性 义 有 value 属 性 

* 2、 存 在 ref 属 性 或 者 value 属 性 且 叉 有 子 元 素 
T 


error(elementName + 











" is only allowed to contain either 'ref' attribute OR 'value' 
attribute OR sub-element", ele); 
j 
if (hasRefAttribute) ( 
/ref 属 性 的 处 理 ， 使 用 RuntimeBeanReference 封 装 对 应 的 ref 名 
称 
String refName = ele.getAttribute(REF_ATTRIBUTE); 
if (!StringUtils.hasText(refName)) { 
error(elementName + " contains empty Tef attribute", ele); 
} 
RuntimeBeanReference ref = new 
RuntimeBeanReference(refName); 
ref.setSource(extractSource(ele)); 
return ref; 
Jelse if (hasValueAttribute) { 
/value 属 性 的 处 理 ， 使 用 TypedStringValue 封 装 
TypedString Value valueHolder = new TypedStringValue 
(ele.getAttribute 
(VALUE ATTRIBUTE)); 
valueHolder.setSource(extractSource(ele)); 
return valueHolder; 


Jelse if (subElement !- null) { 


/解析 子 元 素 
return parsePropertySubElement(subElement, bd); 
}else { 
// 既 没有 ref 也 没有 value 也 没有 子 元 素 ，Spring 蒙 圈 了 
error(elementName + " must specify a ref or value", ele); 


return null; 


} 
从 代码 上 来 看 ， 对 构造 函数 中 属性 元 素 的 解析 ， 经 历 了 以 下 几 个 过 





(1) 略 过 description 或 者 meta。 
(2) 提取 constructor-arg 上 的 ref 和 value 属 性 ， 以 便于 根据 规则 验证 
正确 性 ， 其 规则 为 在 constructor-arg 上 不 存在 以 下 情况 。 
同时 既 有 ref 属 性 又 有 value 属 性 。 
存在 ref 属 性 或 者 value 属 性 且 又 有 子 元 素 。 
(3) ref 属 性 的 处 理 。 使 用 RuntimeBeanReference 封 装 对 应 的 ref 名 
称 ， 如 : 
<constructor-arg ref="a" > 
(4) value 属 性 的 处 理 。 使 用 TypedStringValue 封 装 ， 例 如 : 
<constructor-arg value="a" > 
(5) 子 元 素 的 处 理 。 例 如 : 


<constructor-arg> 














<map> 
<entry key="key" value="value" /> 
</map> 
</constructor-arg> 


而 对 于 子 元 素 的 处 理 ， 例 如 这 里 提 到 的 在 构造 函数 中 又 租 入 了 子 元 





z& map 是 怎么 实现 的 呢 ? parsePropertySubElement 中 实现 了 对 各 种 子 元 
素 的 分 类 处 理 。 
public Object parsePropertySubElement(Element ele, BeanDefinition 
bd) { 
return parsePropertySubElement(ele, bd, null); 
j 
public Object parsePropertySubElement(Element ele, BeanDefinition 
bd, String defaultValueType) 1 
if ('isDefaultNamespace(ele)) 1 
return parseNestedCustomElement(ele, bd); 
j 
else if (nodeNameEquals(ele, BEAN ELEMENT)) { 
BeanDefinitionHolder nestedBd - 
parseBeanDefinitionElement(ele, bd); 
if (nestedBd != null) { 
nestedBd = decorateBeanDefinitionIfRequired(ele, nestedBd, 
bd); 
} 
return nestedBd; 
} 
else if (nodeNameEquals(ele, REF_ELEMENT)) { 
// A generic reference to any name of any bean. 
String refName = ele.getAttribute(BEAN REF ATTRIBUTE); 
boolean toParent - false; 
if (IStringUtils.hasLength(refName)) { 
/解析 local 
refName = ele.getAttribute(LOCAL REF ATTRIBUTE); 


if (IStringUtils.hasLength(refName)) { 
/解析 parent 
refName = ele.getAttribute(PARENT_REF_ATTRIBUTE); 
toParent = true; 
if (IStringUtils.hasLength(refName)) { 
error(""bean’, ‘local’ or parent is required for <ref> 
element", ele); 


return null; 


} 
if (!StringUtils.hasText(refName)) { 
error("<ref> element contains empty target attribute", ele); 
return null; 
} 
RuntimeBeanReference ref = new 
RuntimeBeanReference(refName, toParent); 
ref.setSource(extractSource(ele)); 


return ref; 


} 
Xtidret 70 Hs BAT 
else if (nodeNameEquals(ele, IDREF_ELEMENT)) { 
return parseIdRefElement(ele); 
} 
/对 value 子 元 又 的 解析 
else if (nodeNameEquals(ele, VALUE_ELEMENT)) { 


return parseValueElement(ele, defaultValueType); 


} 

/对 null 子 元 素 的 解析 

else if (nodeNameEquals(ele, NULL_ELEMENT)) { 
// It's a distinguished null value. Let's wrap it in a 

TypedStringValue 

// object in order to preserve the source location. 
TypedStringValue nullHolder = new TypedString Value(null); 
nullHolder.setSource(extractSource(ele)); 
return nullHolder; 

j 

else if (nodeNameEquals(ele, ARRAY ELEMENT)) { 
/解析 array 子 元 素 
return parseArrayElement(ele, bd); 

} 

else if (nodeNameEquals(ele, LIST ELEMENT)) { 
/解析 list 子 元 素 
return parseListElement(ele, bd); 

} 

else if (nodeNameEquals(ele, SET ELEMENT)) { 
/解析 set 子 元 素 
return parseSetElement(ele, bd); 

} 

else if (nodeNameEquals(ele, MAP ELEMENT)) { 
/解析 map 子 元 素 
return parseMapElement(ele, bd); 

} 

else if (nodeNameEquals(ele, PROPS ELEMENT)) { 


/解析 props 子 元 素 
return parsePropsElement(ele); 
} 
else { 
error("Unknown property sub-element: [" + ele.getNodeName() + 
"|", ele); 


return null; 


} 

可 以 看 到 ， 在 上 面 的 函数 中 实现 了 所 有 可 文 持 的 子 类 的 分 类 处 理 ， 
到 这 里 ， 我 们 已 经 大 致 理 清 构 造 函 数 的 解析 流程 ， 至 于 再 深入 的 解析 读 
者 有 兴趣 可 以 自己 去 探索 。 

7. 解析 子 元 素 property 

parsePropertyElement 函 数 完 成 了 对 property 属 性 的 提取 ，Pproperty 使 
用 方式 如 下 : 


<bean id="test" class="test.TestClass"> 





<property name="testStr" value="aaa"/> 
</bean> 
或 者 
<bean id="a"> 
<property name="p"> 
<list> 
<value>aa</value> 
<value>bb</value> 
</list> 
</property> 


</bean> 


而 具体 的 解析 过 程 如 下 : 
public void parsePropertyElements(Element beanEle, BeanDefinition 
bd) { 
NodeList nl = beanEle.getChildNodes(); 
for (int i = 0; i < nl.getLength(); i++) 1 
Node node - nl.item(i); 
if (isCandidateElement(node) && nodeNameEquals(node, 
PROPERTY ELEMENT)) 1 
parsePropertyElement((Element) node, bd); 


j 

有 了 之 前 分 析 构 造 函 数 的 经 验 ， 这 个 函数 我 们 并 不 难 理解 ， 无 非 是 
提取 所 有 property 的 子 元 素 ， 然 后 调用 parsePropertyElement 处 理 ， 
parsePropertyElement 代 人 码 如 下 : 

public void parsePropertyElement(Element ele, BeanDefinition bd) { 

1/ 获取 配置 元 素 中 name 的 值 
String propertyName = ele.getAttribute(NAME ATTRIBUTE); 
if (!StringUtils.hasLength(propertyName)) 1 





error(" Tag 'property' must have a 'name' attribute", ele); 
return; 
j 
this.parseState.push(new PropertyEntry(propertyName)); 
try 1 
/不 允许 多 次 对 同一 属性 配置 
if (bd.getProperty Values().contains(propertyName)) 1 
error("Multiple ‘property’ definitions for property " + 


propertyName + """, ele); 
return; 

j 
Object val = parseProperty Value(ele, bd, propertyName); 
Property Value pv = new Property Value(propertyName, val); 
parseMetaElements(ele, pv); 
pv.setSource(extractSource(ele)); 
bd.getProperty Values().addProperty V alue(pv); 

j 

finally { 
this.parseState.pop(); 


} 

可 以 看 到 上 面 函数 与 构造 函数 注入 方式 不 同 的 是 将 返回 值 使 用 
PropertyValue 进 行 封装 ， 并 记录 在 了 BeanDefinition 中 的 propertyValues 属 
性 中 。 

8. HENT T JICA qualifier 

对 于 qualifier 元 素 的 获取 ， 我 们 接触 更 多 的 是 注解 的 形式 ， 在 使 用 
Spring 框架 中 进行 自动 注入 时 ，Spring 容 器 中 匹配 的 候选 Bean 数 目 必须 
有 且 仪 有 一 个 。 当 找 不 到 一 个 匹配 的 Bean 时 ， Spring 容器 将 抛 出 
BeanCreationException 寞 常 ， 并 指出 必须 至 少 拥 有 一 个 匹配 的 Bean。 

Spring 人 允许 我 们 通过 Qualifier 指 定 注 入 Bean 的 名 称 ， 这 样 卜 义 就 消 
除了 ， 而 对 于 配置 方式 使 用 如 : 


<bean id="myTestBean" class="bean.MyTestBean"> 








<qualifier 
type="org.Springframework.beans.factory.annotation. Qualifier" value="qf"/> 


</bean> 








其 解析 过 程 与 之 前 大 同 小 异 ， 这 里 不 再 重复 叙述 。 
3.1.2 AbstractBeanDefinition 属 性 


至 此 我 们 便 完 成 了 对 XML 文档 到 GenericBeanDefinition 的 转换 ， 也 
就 是 说 到 这 里 ，XML 中 所 有 的 配置 都 可 以 在 GenericBeanDefinition 的 实 
例 类 中 找到 对 应 的 配置 。 

GenericBeanDefinition 只 是 子 类 实现 ， 而 大 部 分 的 通用 属性 都 保存 
在 了 AbstractBeanDefinition 中 ， 那 么 我 们 再 次 通过 AbstractBeanDefinition 
的 属性 来 回顾 一 下 我 们 都 解析 了 哪些 对 应 的 配置 。 


public abstract class AbstractBeanDefinition extends 





BeanMetadataAttributeAccessor 


implements BeanDefinition, Cloneable { 


// 此 处 省 略 静 态 变 量 以 及 final 和 常量 





[RK 
* bean 的 作用 范围 ,对 应 bean 属 性 scope 
*/ 
private String scope = SCOPE_DEFAULT; 
[RK 
* 是 人 否 是 单 例 ,来 自 bean 属 性 scope 
*/ 
private boolean singleton = true; 
[RK 
* 是 否 是 原型 ,来 自 bean 属 性 scope 
*/ 


private boolean prototype = false; 


[RK 


* 是 否 是 抽象 ， 对 应 bean 属 性 abstract 


*/ 
private boolean abstractFlag = false; 
[RK 
* 是 否 延 迟 加 载 ,对 应 bean 属 性 ljazy-init 
*/ 
private boolean lazyInit = false; 
[RK 
* 自动 注入 模式 ,对 应 bean 属 性 autowire 
ay 
private int autowireMode = AUTOWIRE_NO; 
[** 
*+ 依 赖 检 查 ，Spring 3.0 后 弃 用 这 个 属性 
*/ 
private int dependencyCheck = DEPENDENCY_CHECK_NONE; 
/ 米 米 
* 用 来 表示 一 个 bean 的 实例 化 依靠 另 一 个 bean 先 实例 化 ,对 应 bean 
属性 depend-on 
"sj 
private String[] dependsOn; 
/ 米 米 
* autowire-candidate 属 性 设置 为 false， 这 样 容器 在 查找 自动 装配 
对 象 时 ， 
* 将 不 考虑 该 bean， 即 它 不 会 被 考虑 作为 其 他 bean 目 动 装配 的 候 
选 者 ， 但 是 该 bean 本 号 还 是 可 以 使 用 自动 
装配 来 注入 其 他 bean 的 。 
* 对 应 bean 属 性 autowire-candidate 
9l 





private boolean autowireCandidate = true; 


/ 米 米 
* 自动 装配 时 当 出 现 多 个 bean 候 选 者 时 ， 将 作为 首选 者 ,对 应 bean 
属性 primary 
*/ 
private boolean primary = false; 
[** 
* 用 于 记录 Qualifier， 对 应 子 元 素 qualifier 
*/ 


private final Map<String, AutowireCandidateQualifier> qualifiers = 
new LinkedHashMap<String, AutowireCandidateQualifier>(0); 
[ee 

* 允许 访问 非 公 开 的 构造 器 和 方法 ， 程 序 设 置 

*/ 
private boolean nonPublicAccessAllowed = true; 
LI 

* 是 否 以 一 种 客 松 的 模式 解析 构造 函数 ， 默 认为 true,， 

* 如 果 为 false, 则 在 如 下 情况 

* interface ITest{} 

* class ITestImpl implements ITest{ }; 

* class Main{ 

* Main(ITest i){ } 

* Main(ITestImpl i){ } 

Ty 
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* 程序 设置 

sa 


private boolean lenientConstructorResolution = true; 


[** 
* 记录 构造 函数 注入 属性 ， 对 应 bean 属 性 constructor-arg 
gi 
private ConstructorArgumentValues constructorArgumentValues; 
[** 
* 普通 属性 集合 
T 


private MutableProperty Values property Values; 


/ 米 米 


* 方法 重 写 的 持 有 者 ,记录 lookup-method、replaced-method 元 


素 
*/ 
private MethodOverrides methodOverrides = new 
MethodOverrides(); 
[** 


* 对 应 bean 属 性 factory-bean， 用 法 : 
* <bean id="instanceFactoryBean" 
class="example.chapter3.InstanceFactoryBean"/> 
* <bean id="currentTime" factory-bean="instanceFactoryBean" 
factory-method=" 
create Time"/> 
*/ 
private String factoryBeanName; 
[** 
* 对 应 bean 属 性 factory-method 
*/ 


private String factoryMethodName; 





/ 米 米 
* 初始 化 方法 ， 对 应 bean 属 性 init-method 
*/ 
private String initMethodName; 
/ 米 米 
* 销毁 方法 ， 对 应 bean 属 性 destory-method 
*/ 
private String destroyMethodName; 
/ 米 米 
* 是 否 执行 init-method， 程 序 设置 
*/ 
private boolean enforceInitMethod = true; 
/ 米 米 
* 是 否 执行 destory-method， 程 序 设置 
*/ 


private boolean enforceDestroyMethod = true; 
/ 米 米 
* 是 否 是 用 户 定 义 的 而 不 是 应 用 程序 本 里 定义 的 ,创建 AOP 时 
候 为 tue， 程 序 设 置 
"i 


private boolean synthetic = false; 








peek 
* 定义 这 个 bean 的 应 用 » APPLICATION: 用 户 ， 
INFRASTRUCTURE: 2&4 SSH. 5HP X. SUPPORT: 
某 些 复杂 配置 的 一 部 分 
* 程序 设置 





*/ 
private int role = BeanDefinition.ROLE APPLICATION; 


[RK 
* bean 的 描述 信息 
*/ 
private String description; 
[RK 
这 个 bean 定 义 的 资源 
*/ 


private Resource resource; 


// 此 处 省 略 set/get 方 法 





到 这 里 我 们 已 经 完成 了 分 析 默 认 标 签 的 解析 与 提取 过 程 ， 或 许 涉 及 
的 内 容 太 多 ， 我 们 已 经 态 了 我 们 从 哪个 函数 开始 的 了 ， 我 们 再 次 回顾 下 
默认 标签 解析 函数 的 起 始 函 数 : 
protected void processBeanDefinition(Element ele, 
BeanDefinitionParserDelegate delegate) { 
BeanDefinitionHolder bdHolder = 
delegate.parseBeanDefinitionElement(ele); 
if (bdHolder != null) { 
bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, 
bdHolder); 
try { 
// Register the final decorated instance. 


BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, 


getReader 
Context().getRegistry()); 
j 
catch (BeanDefinitionStoreException ex) { 
getReaderContext().error(" Failed to register bean definition with 
name ”十 
bdHolder.getBeanName() + "", ele, ex); 
} 
// Send registration event. 
getReaderContext().fireComponentRegistered(new 
BeanComponentDefinition 
(bdHolder)); 
} 

} 

我 们 已 经 用 了 大 量 的 篇 幅 分 析 了 BeanDefinitionHolder bdHolder = 
delegate.parseBean DefinitionElement(ele) 这 人 句 代 码 ， 接 下 来 ， 我 们 要 进 
行 bdHolder = delegate.decorateBean DefinitionIfRequired(ele, bdHolder) 代 
码 的 分 析 ， 首 先 大 致 了 解 下 这 人 句 代 码 的 作用 ， 其 实 我 们 可 以 从 语义 上 分 
Br: 如 果 需 要 的 话 就 对 beanDefinition 进 行 装饰 ， 那 这 句 代 码 到 底 是 什么 
功能 呢 ? 其 实 这 人 句 代 码 适用 于 这 样 的 场景 ， 如 : 


<bean id="test" class="test.MyClass"> 





<mybean:user username="aaa""/> 
</bean> 
当 Spring 中 的 bean 使 用 的 是 默认 的 标 俭 配置 ， 但 是 其 中 的 子 元 素 却 
使 用 了 目 定 义 的 配置 时 ， 这 名 代码 便 会 起 作用 了 。 可 能 有 人 会 有 疑问 ， 
之 前 讲 过 ， 对 bean 的 解析 分 为 两 种 类 型 ， 一 种 是 默认 类 型 的 解析 ， 田 
一 种 是 自 定义 类 型 的 解析 ， 这 不 正 是 自 定 义 类 型 的 解析 吗 ? 为 什么 会 在 








默认 类 型 解析 中 单独 添加 一 个 方法 处 理 呢 ? 确实 ， 这 个 问题 很 让 人 迷 
惑 ， 但 是 ， 不 知道 聪明 的 读者 是 否 有 发现 ， 这 个 自 定义 类 型 并 不 是 以 
Bean 的 形式 出 现 的 呢 ? 我 们 之 前 讲 过 的 两 种 类 型 的 不 同 处 理 只 是 针对 
Bean 的 ， 这 里 我 们 看 到 ， 这 个 目 定义 类 型 其 实 是 属性 。 好 了 ， 我 们 继 
续 分 析 下 这 段 代码 的 逻辑 。 
public BeanDefinitionHolder 
decorateBeanDefinitionIfRequired(Element ele, BeanDefinitionHolder 
definitionHolder) 1 
return decorateBeanDefinitionIfRequired(ele, definitionHolder, null); 
j 
这 里 将 函数 中 第 三 个 参数 设置 为 空 ， 那 么 第 三 个 参数 是 做 什么 用 的 
We? 什么 情况 下 不 为 空 呢 ?其 实 这 第 三 个 参数 是 父 类 bean, HEA 
仍 套 配置 进行 分 析 时 ， 这 里 需要 传递 父 类 beanDefinition。 分 析 源 码 得 知 
这 里 传递 的 参数 其 实 是 为 了 使 用 父 类 的 scope 属 性 ， 以 备 子 类 各 没有 设 
置 scope 时 默认 使 用 父 类 的 属性 ， 这 里 分 析 的 是 顶层 配置 ， 所 以 传递 
null。 将 第 三 个 参数 设置 为 空 后 进一步 跟踪 函数 : 
public BeanDefinitionHolder decorateBeanDefinitionIfRequired( 
Element ele, BeanDefinitionHolder definitionHolder, BeanDefinition 
containingBd) { 
BeanDefinitionHolder finalDefinition = definitionHolder; 
NamedNodeMap attributes = ele.getAttributes(); 
(GI PA VE, Aree ees HT ETSI Js PE 


for (int i = 0; i < attributes.getLength(); i++) 1 








Node node - attributes.item(i); 
finalDefinition =decorateIfRequired(node, finalDefinition, 
containingBd); 


} 


NodeList children = ele.getChildNodes(); 
(HAAS, Bae GUB EUM THe PCR 
for (int i = 0; i < children.getLength(); i++) { 











Node node = children.item(i); 
if (node.getNodeType() == Node.ELEMENT_NODE) { 
finalDefinition =decorateIfRequired(node, finalDefinition, 
containingBd); 
j 
j 
return finalDefinition; 
j 
上 面 的 代码 ， 我 们 看 到 函数 分 别 对 元 素 的 所有 属性 以 及 子 节点 进行 
了 decorateIfRequired 函 数 的 调用 ， 我 们 继续 跟踪 代码 : 
private BeanDefinitionHolder decorateIfRequired( 
Node node, BeanDefinitionHolder originalDef, BeanDefinition 
containingBd) { 
/获取 目 定 义 标 签 的 命名 空间 
String namespaceUri = getNamespaceURI(node); 
/对 于 非 默认 标签 进行 修饰 
if (tisDefaultNamespace(namespaceUri)) { 
IT n i 4 T TR] D BI NY ve EIS] ABRE AF 


NamespaceHandler handler = this.readerContext. 





getNamespaceHandler Resolver(). 
resolve(namespaceUri); 
if (handler != null) { 
/进行 修饰 


return handler.decorate(node, originalDef, new 


ParserContext(this.readerContext, 
this, containingBd)); 
} 
else if (namespaceUri != null && namespace Uri.startsWith("http: 
/www. 
Springframework.org/")) { 
error("Unable to locate Spring NamespaceHandler for XML 
schema namespace 
[" + namespaceUri + "]", node); 
j 
else { 


// A custom namespace, not to be handled by Spring - maybe 


if (logger.isDebugEnabled()) 1 
logger.debug("No Spring NamespaceHandler found for XML 
schema 


namespace [" + namespaceUri + "|"); 


j 
return originalDef; 
j 
public String getNamespaceURI(Node node) { 
return node.getNamespaceURI(); 
j 
public boolean isDefaultNamespace(String namespaceUri) 1 
//(BEANS NAMESPACE URI = 


"http://www.Springframework.org/schema/beans"; 
return (!StringUtils.hasLength(namespaceUri) || 
BEANS NAMESPACE URI.equals 
(namespaceUri)); 

j 

程序 走 到 这 里 ， 条 理 其 实 已 经 非常 清楚 了 ， 首 先 获 取 属 性 或 者 元 素 
的 命名 空间 ， 以 此 来 判断 该 元 素 或 者 属性 是 否 适 用 于 自 定义 标签 的 解析 
条 件 ， 找 出 自 定 义 类 型 所 对 应 的 NamespaceHandler 并 进行 进一步 解析 。 
在 目 定义 标签 解析 的 章节 我 们 会 重点 讲解 ， 这 里 暂时 先 略 过 。 

我 们 总 结 下 decorateBeanDefinitionIfRequired 方 法 的 作用 ， 在 
decorateBeanDefinitionIfRequired 中 我 们 可 以 看 到 对 于 程序 默认 的 标签 的 
处 理 其 实 是 直接 略 过 的 ， 因 为 默认 的 标签 到 这 里 已 经 被 处 理 完 了 ， 这 里 
只 对 上 自 定义 的 标签 或 者 说 对 bean 的 目 定义 属性 感 兴趣 。 在 方法 中 实现 
了 寻找 自 定 义 标 签 并 根据 自 定义 标签 寻找 命名 空间 处 理 器 ， 并 进行 进 一 
步 的 解析 。 

3.1.4 注册 解析 的 BeanDefinition 

对 于 配置 文件 ， 解 析 也 解析 完了 ， 装 饰 也 装饰 完了 ， 对 于 得 到 的 
beanDinition 已 经 可 以 满足 后 续 的 使 用 要 求 了 ， 唯 一 还 剩 下 的 工作 惑 是 
注册 了 ， 人 也 就 是 processBeanDefinition 函 数 中 的 
BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, 


getReaderContext().getRegistry()) 代 码 的 解析 了 。 


public static void registerBeanDefinition( 








BeanDefinitionHolder definitionHolder, BeanDefinitionRegistry 
registry) 
throws BeanDefinitionStoreException { 


/使 用 beanName 做 唯一 标识 注册 


String beanName = definitionHolder.getBeanName(); 
registry.registerBeanDefinition(beanName, 
definitionHolder.getBeanDefinition()); 
/注册 所 有 的 别名 
String[] aliases = definitionHolder.getAliases(); 
if (aliases != null) { 
for (String aliase : aliases) { 


registry.registerAlias(beanName, aliase); 


} 

从 上 面 的 代码 可 以 看 出 ， 解 析 的 beanDefinition 都 会 被 注册 到 
BeanDefinitionRe gisuys 型 的 实例 registry 中 ， m 于 beanDefinition 的 注 
册 分 成 了 两 部 分 : 通过 beanName 的 注册 以 及 通过 别名 的 注册 。 

1. 通过 beanName 注 册 BeanDefinition 

对 于 beanDefinition 的 注册 ， 或 许 很 多 人 认为 的 方式 就 是 将 
beanDefinition 直接 放 入 map HF Wiig Y, (H beanName (EWA key. fff 
SE, Spring HERA, AARP, Exit SA AIA SET e 

public void registerBeanDefinition(String beanName, BeanDefinition 
beanDefinition) 

throws BeanDefinitionStoreException { 

Assert.hasText(beanName, "Bean name must not be empty"); 
Assert.notNull(beanDefinition, "BeanDefinition must not be null"); 
if (beanDefinition instanceof AbstractBeanDefinition) 1 
try 1 
/* 
* 注册 前 的 最 后 一 次 校 验 ， 这 里 的 校 验 不 同 于 之 前 的 XML 


文件 校 验 ， 
* 主要 是 对 于 AbstractBeanDefinition 属 性 中 的 
methodOverrides 校 验 ， 
* 校 验 methodOverrides 是 否 与 工厂 方法 并 存 或 者 
methodOverrides 对 应 的 方法 根本 不 存在 
*/ 
((AbstractBeanDefinition) beanDefinition).validate(); 
} 


catch (BeanDefinitionValidationException ex) { 








throw new BeanDefinitionStoreException (beanDefinition. 
getResource 
Description(), beanName, 


"Validation of bean definition failed", ex); 


} 
/因为 beaanDefinitionMap 是 全 局 变量 ， 这 里 定 会 存在 并 发 访问 的 








synchronized (this.beanDefinitionMap) { 
Object oldBeanDefinition = 
this.beanDefinitionMap.get(beanName); 
/处 理 注册 已 经 注册 的 beanName 情 况 
让 (oldBeanDefinition != null) { 
/如 果 对 应 的 BeanName 已 经 注册 且 在 配置 中 配置 了 bean 不 允 
VOC tit» NUT EA 


if (!this.allowBeanDefinitionOverriding) { 








throw new BeanDefinitionStoreException(beanDefinition. 


getResource 


Description(), beanName, 

"Cannot register bean definition [" + beanDefinition + 

"] for bean " + beanName + 

"': There is already [" + oldBeanDefinition + "] bound."); 

jelse 1 

if (this.logger.isInfoEnabled()) { 

this.logger.info("Overriding bean definition for bean " + 
beanName + 

"': replacing [" + oldBeanDefinition + "] with [" 


+ beanDefinition + "]"); 


} 
jelse { 
/记录 beanName 
this.beanDefinitionNames.add(beanName); 
this.frozenBeanDefinitionNames = null; 
} 
/注册 beanDefinition 
this.beanDefinitionMap.put(beanName, beanDefinition); 
} 
// 重 置 所 有 beanName 对 应 的 缓存 
resetBeanDefinition(beanName); 
} 
上 面 的 代码 中 我 们 看 到 ， 在 对 于 bean 的 注册 处 理 方式 上 ， 主 要 进行 
了 几 个 步骤 。 
(1) 对 AbstractBeanDefinition 的 校 验 。 在 解析 XML 文件 的 时 候 我 
们 提 过 校 验 ， 但 是 此 校 验 非 彼 校 验 ， 之 前 的 校 验 时 针对 于 XML 格式 的 








校 验 ， 而 此 时 的 校 验 时 针 是 对 于 AbstractBean Definition) 
methodOverrides 属 性 的 。 
(2) 对 beanName 己 经 注册 的 情况 的 处 理 。 如 果 设 置 了 不 允许 bean 
Hyg ae We EDO ay, PY AIA m o 
(3) 加 入 map 绥 存 。 
(4) 清除 解析 之 前 留 下 的 对 应 beanName 的 绥 存 。 
2. 通过 别名 注册 BeanDefinition 
在 理解 了 注册 bean 的 原理 后 ， 理 解 注 册 别 名 的 原理 就 容易 多 了 。 


public void registerAlias(String name, String alias) { 








Assert.hasText(name, "name' must not be empty"); 


"v 


Assert.hasText(alias, "alias' must not be empty"); 
/如 果 beanName 与 alias 相 同 的话 不 记录 alias, 并 删除 对 应 的 alias 
if (alias.equals(name)) { 
this.aliasMap.remove(alias); 
}else { 
//t alias 7S fb VFR s UI 3 HH p 5$ 
if ('allowAliasOverriding()) { 
String registeredName = this.aliasMap.get(alias); 
if (registeredName !- null && !registeredName.equals(name)) { 
throw new IllegalStateException(" Cannot register alias "' + 
alias 
*" for name "' + 
name + "": It is already registered for name "+ 


registeredName + "."); 


j 
/ 当 A->B 存 在 时 ， 若 再 次 出 现 A->C->B 时 候 则 会 抛 出 异常 


checkForAliasCircle(name, alias); 


this.aliasMap.put(alias, name); 


} 

由 以 上 代码 中 可 以 得 知 注册 alias 的 步骤 如 下 。 

(1) alias 与 beaanName 相 同情 况 处 理 。 知 alias 与 beaanName 并 名 称 相 
同 则 不 需要 处 理 并 删除 挥 原 有 alias。 

(2) alias 履 盖 处 理 。 若 aliasName 已 经 使 用 并 已 经 指向 了 另 一 
beanName 则 需要 用 户 的 设置 进行 处 理 。 

(3) alias 循 环 检查 。 当 A->B 存 在 时 ， 若 再 次 出 现 A->C->B 时 候 则 
会 抛 出 异常 。 

(4) 注册 alias。 





ift AB getReaderContext().fireComponentRegistered(new 
BeanComponentDefinition(bdHolder)) 完 成 此 工作 ， 这 里 的 实现 只 为 扩 
展 ， 当 程序 开发 人 员 需 要 对 注册 BeanDefinition 事 件 进行 监听 时 可 以 通过 
注册 监听 器 的 方式 并 将 处 理 逻 辑 写 入 监听 器 中 ， 目 前 在 Spring 中 并 没有 
对 此 事件 做 任何 人 逻辑 处 理 。 


32 alias 标 签 的 解 


通过 上 面 较 长 的 篇 幅 我 们 终于 分 析 完 了 默认 标签 中 对 bean 标签 的 
处 理 ， 那 么 我 们 之 前 提 到 过 ， 对 配置 文件 的 解析 包括 对 import 标 签 、 
alias 标 签 、bean 标 签 、beans 标 签 的 处 理 ， 现 在 我 们 已 经 完成 了 最 重要 也 
是 最 核心 的 功能 ， 其 他 的 解析 步 又 也 都 是 围绕 第 3 个 解析 而 进行 的 。 在 
分 析 了 第 3 个 解析 步骤 后 ， 再 回 过 头 来 看 看 对 alias 标 签 的 解析 。 

在 对 bean 进 行 定义 时 ， 除 了 使 用 id 属性 来 指定 名 称 之 外 ， 为 了 提供 





多 个 名 称 ， 可 以 使 用 alias 标 签 来 指定 。 而 所 有 的 这 些 名 称 都 指向 同一 个 
bean， 在 茶 些 情况 下 提供 别名 非常 有 用 ， 比 如 为 了 让 应 用 的 每 一 个 组 件 
能 更 容易 地 对 公共 组 件 进行 引用 。 

然而 ， 在 定义 bean 时 就 指定 所 有 的 别名 并 不 是 总 是 恰当 的 。 有 时 
我 们 期 望 能 在 当前 位 置 为 那些 在 别处 定义 的 bean 引入 别名 。 在 XML fic 
置 文件 中 ， 可 用 单独 的 <alias/> 元 素来 完成 bean 列 名 的 定义 。 如 配置 文件 
中 定义 了 一 个 JavaBean: 

<bean id="testBean" class="com.test"/> 

要 给 这 个 JavaBean 增 加 别名 ， 以 方便 不 同 对 象 来 调用 。 我 们 就 可 以 
直接 使 用 bean 标 签 中 的 name 属 性 : 

<bean id="testBean" name="testBean,testBean2" class="com.test"/> 

同样 ，Spring 还 有 另外 一 种 声明 别名 的 方式 : 


<bean id="testBean" class="com.test"/> 








<alias name="testBean" alias="testBean,testBean2"/> 

考虑 一 个 更 为 具体 的 例子 ， 组 件 A 在 XML 配置 文件 中 定义 了 一 个 
名 为 componentA 的 DataSource 类 型 的 bean， 但 组 件 B 却 想 在 其 XML 文件 
中 以 componentB 命 名 来 引用 此 bean。 而 且 在 主 程序 MyApp 的 XML 配置 
文件 中 ， 硕 望 以 myApp 的 名 字 来 引用 此 bean。 最 后 容 絮 加 载 3 个 XML 文 
件 来 生成 最 终 的 ApplicationContext。 在 此 情形 下 ， 可 通过 在 配置 文件 中 
添加 下 列 alias 元 素来 实现 : 

<alias name="componentA" alias="componentB"/> 

«alias name="componentA" alias="myApp" /> 

这 样 一 来 ， 每 个 组 件 及 主 程序 就 可 通过 唯一 名 字 来 引用 同一 个 数据 
源 而 互 不 干扰 。 

在 之 前 的 章节 已 经 讲 过 了 对 于 bean 中 name 元 素 的 解析 ， 那 么 我 们 现 
在 再 来 深入 分 析 下 对 于 alias 标 签 的 解析 过 程 。 


protected void processAliasRegistration(Element ele) { 


/获取 beanName 
String name = ele.getAttribute(NAME ATTRIBUTE); 
// 获 取 alias 
String alias = ele.getAttribute(ALIAS_ATTRIBUTE); 
boolean valid = true; 
if (!StringUtils.hasText(name)) 1 
getReaderContext().error("Name must not be empty", ele); 
valid - false; 
j 
if (!StringUtils.hasText(alias)) 1 
getReaderContext().error(" Alias must not be empty", ele); 
valid - false; 
j 
if (valid) { 
try 1 
/注册 alias 
getReaderContext().getRegistry().registerAlias(name, alias); 
} 
catch (Exception ex) { 
getReaderContext().error(" Failed to register alias "' + alias + 
" for bean with name " + name + '""", ele, ex); 
} 
/别名 注册 后 通知 监听 器 做 相应 处 理 
getReaderContext().fireAliasRegistered(name, alias, 
extractSource(ele)); 


} 


可 以 友 现 ， 跟 之 前 讲 过 的 bean 中 的 alias 解 析 大 同 小 异 ， 都 是 将 别名 
与 beanName 组 成 一 对 注册 至 registry 中 。 这 里 不 再 著述 。 


3.3 importir Wiz 


对 于 Spring 配置 文件 的 编写 ， 我 想 ， 经 历 过 庞大 项 目的 人 ， 都 有 那 
种 恐惧 的 心理 ， 太 多 的 配置 文件 了 。 不 过 ， 分 模块 是 大 多 数 人 能 想到 的 
方法 ， 但 是 ， 怎 么 分 模块 ， 那 就 仁者 见 仁 ， 知 者 见 知 了。 使 用 import 是 
个 好 办 法 ， 例 如 我 们 可 以 构造 这 样 的 Spring 配置 文件 : 
applicationContext.xml 
<?xml version="1.0" encoding="gb2312"?> 
<!DOCTYPE beans PUBLIC "-//Spring//DTD BEAN//EN" 
"http://www.Springframework.org/ 
dtd/Spring-beans.dtd"> 
<beans> 
«import resource="customerContext.xml" /> 
<import resource="systemContext.xml" /> 
</beans> 
applicationContext.xml 文 件 中 使 用 import 的 方式 导入 有 模块 配置 文 
件 ， 以 后 奋 有 新 模块 的 加 入 ， 那 就 可 以 简单 修改 这 个 文件 了 。 这 样 大 大 
简化 了 配置 后 期 维护 的 复杂 度 ， 并 使 配置 模块 化 ， 易 于 管理 。 我 们 来 看 
看 Spring 是 如 何 解析 import 配 置 文件 的 呢 ? 
protected void importBeanDefinitionResource(Element ele) { 
/获取 resource 属 性 
String location = ele.getAttribute(RESOURCE ATTRIBUTE); 
/如 果 不 存 在 resource 属 性 则 不 做 任何 处 理 


if (IStringUtils.hasText(location)) { 


getReaderContext().error(" Resource location must not be empty", 


ele); 
return; 
j 
/解析 系统 属性 ， 格 式 如 : "${user.dir}" 
location = environment.resolveRequiredPlaceholders(location); 
Set<Resource> actualResources = new LinkedHashSet<Resource> 
(4); 


// 判 定 location 是 决定 URI 还 是 相对 URI 
boolean absoluteLocation = false; 
try { 


absoluteLocation = ResourcePatternUtils.isUrl(location) || 
ResourceUtils.toURI 


(location).isAbsolute(); 
} 


catch (URISyntaxException ex) { 


// cannot convert to an URI, considering the location relative 


// unless it is the well-known Spring prefix "classpath*:" 


} 
// Absolute or relative? 
/如 果 是 绝对 URI 则 直接 根据 地 址 加 载 对 应 的 配置 文件 
if (absoluteLocation) { 
try { 
int importCount = 
getReaderContext().getReader().loadBeanDefinitions 


(location, actualResources); 


if (logger.isDebugEnabled()) { 
logger.debug(" Imported " + importCount + " bean definitions 
from 


URL location [" + location + "]"); 


catch (BeanDefinitionStoreException ex) { 
getReaderContext().error( 
"Failed to import bean definitions from URL location [" + 


location + "|", ele, ex); 


} 

} 

else { 
/如 果 是 相对 地 址 则 根据 相对 地 址 计算 出 绝对 地 址 
try { 


int importCount; 

//Resource 存 在 多 个 子 实现 类 ， 如 VfsResource、 
FileSystemResource 等 ， 

/而 每 个 resource 的 createRelative 方 式 实现 都 不 一 样 ， 所 以 这 
里 先 使 用 子 类 的 方法 

尝试 解析 

Resource relativeResource = getReaderContext(). 
getResource(). Create 

Relative(location); 

if (relativeResource.exists()) { 

importCount = getReaderContext().getReader(). 


loadBeanDefinitions 


(relativeResource); 
actualResources.add(relativeResource); 
}else { 
/如 果 解 析 不 成 功 ， 则 使 用 默认 的 解析 器 
ResourcePatternResolver 进 行 解析 
String baseLocation = 
getReaderContext().getResource().getU RI (). 
toString(); 
importCount = 
getReaderContext().getReader().loadBeanDefinitions( 
StringUtils.applyRelativePath(baseLocation, location), 
actual Resources); 
i 
if (logger.isDebugEnabled()) { 
logger.debug(" Imported " + importCount + " bean definitions 
from 


relative location [" + location + "]"); 


catch (IOException ex) 1 
getReaderContext().error(" Failed to resolve current resource 
location", ele, ex); 
j 
catch (BeanDefinitionStoreException ex) { 
getReaderContext().error(" Failed to import bean definitions 
from 


relative location [" + location + "]", 


ele, ex); 


/解析 后 进行 监听 器 激活 处 理 
Resource[] actResArray = actualResources.toArray(new 
Resource[actualResources. size()]); 
getReaderContext().fireImportProcessed(location, actResArray, 
extractSource(ele)); 
} 
上 面 的 代码 不 难 ， 相 信和 配合 注释 会 很 好 理解 ， 我 们 总 结 一 下 大 致 流 
程 便于 读者 更 好 地 梳理 ， 在 解析 <import 标 签 时 ，Spring 进 行 解析 的 步 又 
大 致 如 下 。 
(1) 获取 resource 属 性 所 表示 的 路 径 。 
(20 解析 路 径 中 的 系统 属性 ， 格 式 如 “${user.dir}”。 
(3) 判定 location 是 绝对 路 径 还 是 相对 路 径 。 
(4) 如 果 是 绝对 路 径 则 递归 调用 bean 的 解析 过 程 ， 进 行 另 一 次 的 
解析 。 
(50 如 有 果 是 相对 路 径 则 计算 出 绝对 路 径 并 进行 解析 。 
(6) 通知 监听 器 ， 解 析 完 成 。 
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类 似 于 import 标 签 所 提供 的 功能 ， 使 用 如 下 : 

<?xml version="1.0" encoding="UTF-8"?> 

«beans xmlns="http://www.Springframework.org/schema/beans" 


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www.Springframework. 
org/schema/beans/Spring-beans.xsd"> 
<bean id="aa" class="test.aa"/> 
<beans> 
</beans> 
</beans> 
XI FERAI beans 标签 来 讲 ， 并 没有 太 多 可 讲 ， 与 单独 的 配置 文件 
并 没有 太 大 的 差别 ， 无 非 是 递归 调用 beans 的 解析 过 程 ， 相 信 读 者 根据 
之 前 讲解 过 的 内 容 已 经 有 能 力 理解 其 中 的 奥秘 了 。 


第 4 章 定义 标签 出 

在 之 前 的 章节 中 ， 我 们 提 到 了 在 Spring 中 存在 默认 标签 与 自 定 义 标 
签 两 种 ， 而 在 上 一 章节 中 我 们 分 析 了 Spring 中 对 默认 标签 的 解析 过 程 ， 
相信 大 家 一 定 已 经 有 所 感悟 。 那 么 ， 现 在 将 开始 新 的 里 程 ， 分 析 Spring 
中 上 自 定 义 标 签 的 加 载 过 程 。 同 样 ， 我 们 还 是 先 再 次 回顾 一 下 ， 当 完成 从 
配置 文件 到 Document 的 转换 并 提取 对 应 的 root 后 ， 将 开始 了 所 有 元 素 的 
解析 ， 而 在 这 一 过 程 中 便 开 始 了 默认 标签 与 自 定义 标签 两 种 格式 的 区 
分 ， 函 数 如 下 : 


protected void parseBeanDefinitions(Element root， 





BeanDefinitionParserDelegate delegate) { 
if (delegate.isDefaultNamespace(root)) { 
NodeList nl = root.getChildNodes(); 
for (int i = 0; i < nl.getLength(); i++) { 


Node node = nl.item(i); 


if (node instanceof Element) { 
Element ele = (Element) node; 
if (delegate.isDefaultNamespace(ele)) { 
parseDefaultElement(ele, delegate); 
} 
else { 
delegate.parseCustomElement(ele); 


} 


} 

else { 
delegate.parseCustomElement(root); 

} 

} 

在 本 章 中 ， 所 有 的 功能 都 是 围绕 其 中 的 一 句 代码 
delegate.parseCustomElement(roob 开 展 的 。 从 上 面 的 函数 我 们 可 以 看 
出 ， 当 Spring 拿 到 一 个 元 素 时 首先 要 做 的 是 根据 命名 空间 进行 解析 ， 如 
果 是 默认 的 命名 空间 ， 则 使 用 parseDefaultElement 方法 进行 元 素 解析 ， 
否则 使 用 parseCustom Element 方法 进行 解析 。 在 分 析 目 定义 标签 的 解 
析 过 程 前 ， 我 们 先 了 解 一 下 自 定义 标签 的 使 用 过 程 。 


4.1 目 定 义 标签 


We 


在 很 多 情况 下 ， 我 们 需要 为 系统 提供 可 配置 化 文 持 ， 简 单 的 做 法 可 
以 直接 基于 Spring 的 标准 bean 来 配置 ， 但 配置 较为 复杂 或 者 需要 更 多 丰 
富 控 制 的 时 候 ， 会 显得 非常 笨拙 。 一 般 的 做 法 会 用 原生 态 的 方式 去 解析 











定义 好 的 XML 文件 ， 然 后 转化 为 配置 对 象 。 这 种 方式 当然 可 以 解决 所 
有 问题 ， 但 实现 起 来 比较 繁琐 ， 特 别 是 在 配置 非常 复杂 的 时 候 ， 解 析 工 
作 是 一 个 不 得 不 考虑 的 负担 。Spring 提 供 了 可 扩展 Schema 的 文 持 ， 这 是 
一 个 不 错 的 折 中 方案 ， 扩 展 Spring 自 定 义 标签 配置 大 致 需要 以 下 几 个 步 
又 《前提 是 要 把 Spring 的 Core 包 加 入 项 目 中 ) 。 

创建 一 个 需要 扩展 的 组 件 。 

定义 一 个 XSD 文件 摘 述 组 件 内 容 。 

创建 一 个 文件 ， 实 现 BeanDefinitionParser 接 口 ， 用 来 解析 XSD 文件 
中 的 定义 和 组 件 定 义 。 

创建 一 个 Handler 文 件 ， 扩 展 自 NamespaceHandlerSupport， 目 的 是 
将 组 件 注 册 到 Spring 容 器 。 

编写 Spring.handlers 和 Spring.schemas 文 件 。 

现在 我 们 就 按照 上 面 的 步骤 带领 读者 一 步 步 地 体验 自 定 义 标 签 的 过 


(1) 首先 我 们 创建 一 个 普通 的 POJO， 这 个 POJO 没有 任何 特别 之 
处 ， 只 是 用 来 接收 配置 文件 。 
package test.customtag; 
public class User { 
private String userName; 
private String email; 
/省 略 setget 方 法 
} 
(2) 定义 一 个 XSD 文件 描述 组 件 内 容 。 
<?xml version="1.0" encoding="UTF-8"?> 
«schema xmlns="http://www.w3.org/2001/XMLSchema" 
targetNamespace="http://www.lexueba.com/schema/user" 


xmins:tns-"http://www.lexueba.com/schema/user" 


elementFormDefault="qualified"> 
<element name="user"> 
<complexType> 
<attribute name="id" type="string"/> 
<attribute name="userName" type="string"/> 
<attribute name="email" type="string"/> 
</complexType> 
</element> 
</schema> 
在 上 面 的 XSD 文件 中 描述 了 一 个 新 的 targetNamespace， 并 在 这 个 
空间 中 定义 了 一 个 name 为 user 的 element，user 有 3 个 属性 id、userName 
和 email， 其 中 email 的 类 型 为 string。 这 3 个 类 主要 用 于 验证 Spring 配置 文 
件 中 自 定义 格式 。XSD 文 件 是 XML DTD 的 替代 者 ， 使 用 XML Schema 语 
言 进 行 编写 ， 这 里 对 XSD Schema 不 做 太 多 解释 ， 有 兴趣 的 读者 可 以 参 
考 相关 的 资料 。 
(3) 创建 一 个 文件 ， 实 现 BeanDefinitionParser 接 口 ， 用 来 解析 XSD 
文件 中 的 定义 和 组 件 定 义 。 
package test.customtag; 
Import 
org.Springframework.beans.factory.support.BeanDefinitionBuilder; 
import 
org.Springframework.beans.factory.xml.AbstractSingleBeanDefinitionParser; 
import org.Springframework.util. String Utils; 
import org.w3c.dom.Element; 
public class UserBeanDefinitionParser extends 
AbstractSingleBeanDefinitionParser { 
/Element 对 应 的 类 


protected Class getBeanClass(Element element) { 
return User.class; 
} 
/从 element 中 解析 并 提取 对 应 的 元 素 
protected void doParse(Element element, BeanDefinitionBuilder 
bean) { 
String userName = element.getAttribute("userName"); 
String email = element.getAttribute("email"); 
/将 提取 的 数据 放 入 到 BeanDefinitionBuilder 中 ， 待 到 完成 所 
有 bean 的 解析 后 统一 注册 到 
beanFactory 中 
if (StringUtils.hasText(userName)) 1 
bean.addProperty Value("userName", userName); 
j 
if (StringUtils.hasText(email)) 1 


bean.addProperty Value(" email", email); 


j 
(4) 创建 一 个 Handler 文件 ， 扩 展 自 NamespaceHandlerSupport, 
目的 是 将 组 件 注册 到 Spring 容 器 。 
package test.customtag; 
import 
org.Springframework.beans.factory.xml.NamespaceHandlerSupport; 


public class MyNamespaceHandler extends NamespaceHandlerSupport 


public void init() { 


registerBeanDefinitionParser("user", new 
UserBeanDefinitionParser()); 
} 

} 

以 上 代码 很 简单 ， 无 非 是 当 遇 到 目 定 义 标签 <user:aaa 这 样 类 似 于 以 
user FAHR, WEAF T 7G RHI 28 M NLTJUserBeanDefinitionParser 
去 解析 。 

(5) 编写 Spring.handlers 和 Spring. 默认 位 置 是 在 工程 
的 /META-INEF/ 文 件 夹 下 ， 当 然 ， 你 可 以 通过 Spring 的 扩展 或 者 修改 源码 
的 方式 改变 路 径 。 
Spring.handlers 。 





http\://www.lexueba.com/schema/user=test.customtag. MyNamespaceHa! 

Spring.schemas. 

http\://www.lexueba.com/schema/user.xsd=META-INF/Spring-test.xsd 

到 这 里 ， 目 定义 的 配置 就 结束 了 ， 而 Spring 加 载 目 定 义 的 大 致 流程 
是 遇 到 自 定 义 标 签 然后 就 去 Spring.handlers 和 Spring.schemas 中 去 找 对 应 
的 handler 和 XSD， 默 认 位 置 是 /META-INF/ 下 ， 进 而 有 找到 对 应 的 
handler 以 及 解析 元 素 的 Parser， 从 而 完成 了 整个 自 定义 元 素 的 解析 ， 也 
就 是 说 目 定义 与 Spring 中 默认 的 标准 配置 不 同 在 于 Spring 将 自 定 义 标 
签 解析 的 工作 委托 给 了 用 户 去 实现 。 

(6) 创建 测试 配置 文件 ， 在 配置 文件 中 引入 对 应 的 命名 空间 以 及 

XSD 后 ， 便 可 以 直接 使 用 自 定义 标签 了 。 


«beans xmlns="http:/www.Springframework.org/schema/beans" 








xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 


xmlns:myname-"http://www.lexueba.com/schema/user" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 


http://www. 
Springframework.org/schema/beans/Spring-beans-2.0.xsd 
http://www. lexueba.com/schema/user 
http://www.lexueba.com/schema/user.xsd"> 
«myname:user id-"testbean" userName="aaa" email="bbb"/> 
</beans> 
(7) 测试 。 
public static void main(String[] args) { 
ApplicationContext bf = new ClassPathXmlApplicationContext 
("test/customtag/ 
test.xml"); 
User user=(User) bf.getBean( testbean"); 
System.out.printIn(user.getUserName()+","+user.getEmail()); 
} 
不 出 意外 的 话 ， 你 应 该 看 到 了 我 们 期 待 的 结果 ， 控 制 台 上 打印 出 
f: 
aaa,bbb 
在 上 面 的 例子 中 ， 我 们 实现 了 通过 目 定 义 标签 实现 了 通过 属性 的 方 
式 将 user 类 型 的 Bean 赋 值 ， 在 Spring 中 自 定义 标签 非常 常用 ， 例 如 我 们 
熟知 的 事务 标签 : tx(<tx:annotation-driven>)。 


4.2 目 定 义 标签 解 


We 
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定义 标签 的 解析 过 程 。 
public BeanDefinition parseCustomElement(Element ele) { 


return parseCustomElement(ele, null); 


} 
//containingBd 为 父 类 bean， 对 顶层 元 素 的 解析 应 设置 为 null 
public BeanDefinition parseCustomElement(Element ele, 
BeanDefinition containingBd) { 
/获取 对 应 的 命名 空间 
String namespaceUri = getNamespaceURI(ele); 
/根据 命名 空间 找到 对 应 的 NamespaceHandler 
NamespaceHandler handler = 
this.readerContext.getNamespaceHandlerResolver(). 
resolve(namespaceUri); 
if (handler == null) { 
error("Unable to locate Spring NamespaceHandler for XML 
schema namespace [" 
+ namespaceUri + "]", ele); 
return null; 
j 
/调用 自 定 义 的 NamespaceHandler 进 行 解 析 
return handler.parse(ele, new ParserContext(this.readerContext, this, 
containingBd)); 
} 
相信 了 解 了 目 定 义 标 签 的 使 用 方法 后 ， 或 多 或 少 会 对 目 定义 标签 的 
实现 过 程 有 一 个 自己 的 想法 。 其 实 思 路 非常 的 简单 ， 无 非 是 根据 对 应 的 
bean 获取 对 应 的 命名 空间 ， 根 据 命 名 空间 解析 对 应 的 处 理 右 ， 然 后 根据 
用 户 自 定义 的 处 理 句 进行 解析 。 可 是 有 些 事情 说 起 来 简单 做 起 来 难 ， 我 
们 先 看 看 如 何 获 取 命 名 空间 吧 。 


4.2.1 获取 标签 的 命名 空间 











标签 的 解析 是 从 命名 空间 的 提起 开始 的 ， 无 论 是 区 分 Spring 中 默认 
标签 和 上 自 定 义 标 签 还 是 区 分 目 定 义 标签 中 不 同 标签 的 处 理 莫 都 是 以 标签 
所 提供 的 命名 空间 为 基础 的 ， 而 至 于 如 何 提取 对 应 元 了 素 的 命名 空间 其 实 
并 不 需要 我 们 亲自 去 实现 ， 在 org.w3c.dom.Node 中 已 经 提供 了 方法 供 我 
们 直接 调用 : 

public String getNamespaceURI(Node node) 1 








return node.getNamespaceURI(); 


} 
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有 了 命名 空间 ， 就 可 以 进行 NamespaceHandler 的 提取 了 ， 继 续 之 前 
的 parseCustomElement 函 数 的 跟踪 ， 分 析 NamespaceHandler handler = 
this.readerContext.getNamespaceHandlerResolver(). 
resolve(namespaceUri)， 在 readerContext 初 始 化 的 时 候 其 属性 
namespaceHandlerResolver 已 经 被 初始 化 为 了 
DefaultNamespaceHandlerResolver 的 实例 ， 所 以 ， 这 里 调用 的 resolve 77 
法 其 实 调用 的 是 DefaultNamespaceHandlerResolver 类 中 的 方法 。 我 们 进 
入 DefaultNamespaceHandlerResolver 的 resolve 方 法 进行 查看 。 
DefaultNamespaceHandlerResolver.java 
public NamespaceHandler resolve(String namespaceUri) { 
/获取 所 有 已 经 配置 的 handler 映 射 
Map<String, Object> handlerMappings = getHandlerMappings(); 
/根据 命名 空间 找到 对 应 的 信息 
Object handlerOrClassName = handlerMappings.get(namespace Uri); 
if (handlerOrClassName == null) { 
return null; 


}else if (handlerOrClassName instanceof NamespaceHandler) { 


/已 经 做 过 解析 的 情况 ， 直 接 从 绥 存 读 取 
return (NamespaceHandler) handlerOrClassName; 
}else { 
/没有 做 过 解析 ， 则 返回 的 是 类 路 径 
String className = (String) handlerOrClassName; 
try { 
/使 用 反射 将 类 路 径 转 化 为 类 
Class<?> handlerClass = ClassUtils.forName(className, 
this.classLoader); 
if (INamespaceHandler.class.isAssignableFrom(handlerClass)) 


{ 
throw new FatalBeanException("Class [" + className + "| 
for 
namespace [" + namespaceUri + 
"] does not implement the [" + NamespaceHandler. class. 
getName() + "] interface"); 
i 
/初始 化 类 
NamespaceHandler namespaceHandler = (NamespaceHandler) 
BeanUtils. 


instantiateClass(handlerClass); 
// 调 用 自 定义 的 NamespaceHandler 的 初始 化 方法 
namespaceHandler.init(); 

/记录 在 缓存 

handlerMappings.put(namespaceUri, namespaceHandler); 
return namespaceHandler; 


}catch (ClassNotFoundException ex) { 


throw new FatalBeanException("NamespaceHandler class [" + 
className + 
"] for namespace [" + 
namespaceUri + "| not found", ex); 
jcatch (LinkageError err) { 


throw new FatalBeanException(" Invalid NamespaceHandler 


class [" * 
className + "| for namespace [" + 
namespaceUri + "]: problem with handler class file or dependent 
class", err); 
j 
j 
j 


上 面 的 函数 清晰 地 阐述 了 解析 目 定义 NamespaceHandler 的 过 程 ， 
通过 之 前 的 示例 程序 我 们 了 解 到 如 果 要 使 用 目 定义 标签 ， 那 么 其 中 一 项 
必 不 可 少 的 操作 就 是 在 Spring.handlers 文 件 中 配置 命名 空间 与 命名 空间 
处 理 器 的 映射 关系 。 只 有 这 样 ，Spring 才 能 根据 映射 关系 找到 匹配 的 处 
理 器 ， 而 寻找 罗 配 的 处 理 器 就 是 在 上 面 函 数 中 实现 的 ， 当 获取 到 自 定义 
的 NamespaceHandler 之 后 就 可 以 进行 处 理 器 初始 化 并 解析 了 。 我 们 不 
妨 再 次 回忆 一 下 示例 中 对 于 命名 空间 处 理 器 的 内 容 : 


public class MyNamespaceHandler extends NamespaceHandlerSupport 








public void init() 1 
registerBeanDefinitionParser("user", new 
UserBeanDefinitionParser()); 


} 





当 得 到 自 定 义 命名 空间 处 理 后 会 马上 执行 namespaceHandler.init()?K 
进行 目 定 义 Bean DefinitionParser 的 注册 。 在 这 里 ， 你 可 以 注册 多 个 标签 
解析 器 ， 当 前 示例 中 只 有 支持 <myname:user 的 写法 ， 你 也 可 以 在 这 里 注 
册 多 个 解析 器 ， 如 <myname:A、<myname:B 等 ， 使 得 myname 的 命名 空 
间 中 可 以 文 持 多 种 标签 解析 。 

注册 后 ， 命 名 空间 处 理 器 就 可 以 根据 标签 的 不 同 来 调用 不 同 的 解析 
器 进 行 解析 。 那 么 ， 根 据 上 面 的 函数 与 之 前 介绍 过 的 例子 ， 我 们 基本 上 
可 以 推断 getHandlerMappings 的 主要 功能 就 是 读 取 Spring.handlers 配 置 文 
件 并 将 配置 文件 缓存 在 map 中 。 

private Map<String, Object> getHandlerMappings() { 
/如 果 没 有 被 缓存 则 开始 进行 缓存 
if (this.handlerMappings == null) { 











synchronized (this) { 
if (this.handlerMappings == null) { 
try { 
//this.handlerMappingsLocation 在 构造 函数 中 已 经 被 初始 
化 为 :META- 
INF/Spring.handlers 
Properties mappings = 
PropertiesLoaderUtils.loadAllProperties (this. 
handlerMappingsLocation, this.classLoader); 
if (logger.isDebugEnabled()) { 
logger.debug("Loaded NamespaceHandler mappings: " + 
mappings); 
} 
Map<String, Object> handlerMappings = new 
ConcurrentHashMap< 


String, Object>(); 
/将 Properties 格 式 文件 合并 到 Map 格 式 的 
handlerMappings 中 
CollectionUtils.mergePropertiesIntoMap(mappings, 
handlerMappings); 
this.handlerMappings = handlerMappings; 
} 
catch (IOException ex) { 
throw new IllegalStateException( 
"Unable to load NamespaceHandler mappings from 


location [" + this.handlerMappingsLocation + "|", ex); 


} 
return this.handlerMappings; 
} 
同 我 们 想象 的 一 样 ， 借 助 了 工具 类 PropertiesLoaderUtils 对 属性 
handlerMappingsLocation 进 行 了 配置 文件 的 读 取 ， 
handlerMappingsLocation 被 默认 初始 化 为 “META-INF/Spring.handlers”。 


4.2.3 标签 解析 

得 到 了 解析 堪 以 及 要 分 析 的 元 际 后 ，Spring 就 可 以 将 解析 工作 委托 
给 上 日 定义 解析 器 去 解析 了 。 在 Spring 中 的 代码 为 : 

return handler.parse(ele, new ParserContext(this.readerContext, this, 


containingBd)) 
以 之 前 提 到 的 示例 进行 分 析 ， 此 时 的 handler 已 经 被 实例 化 成 为 了 


我 们 自 定 义 的 MyNamespaceHandler 了 ， 而 MyNamespaceHandler 也 已 经 
完成 了 初始 化 的 工作 ， 但 TERRE 的 目 人 空间 处 理 器 中 并 没 
有 实现 parse 方法 ， 所 以 推 凯 ， 这 个 方法 是 父 类 中 的 实现 ， 人 查看 父 类 
NamespaceHandlerSupport 中 的 parse 方 法 。 





NamespaceHandlerSupport.java 
public BeanDefinition parse(Element element, ParserContext 
parserContext) { 
// 寻 找 解 析 器 并 进行 解析 操作 
returnfindParserForElement(element, 
parserContext).parse(element, parserContext); 
} 
解析 过 程 中 首先 是 寻找 元 素 对 应 的 解析 器 ， 进 而 调用 解析 器 中 的 
parse 方法 ， 那 么 结合 示例 来 讲 ， 其 实 束 是 自 先 获取 在 
MyNameSpaceHandler 类 中 的 init 方 法 中 注册 的 对 应 的 UserBean 
DefinitionParser 实 例 ， 并 调用 其 parse 方 法 进行 进一步 解析 。 


private BeanDefinitionParser findParserForElement(Element element, 











ParserContext parser 

Context) { 

/获取 元 素 名 称 ， 也 就 是 <myname:user 中 的 user, 若 在 示例 中 ， 此 
时 localName 为 user 
String localName = 

parserContext.getDelegate().getLocalName(element); 

/根据 user 找 到 对 应 的 解析 器 ， 也 就 是 在 

//registerBeanDefinitionParser("user", new 
UserBeanDefinitionParser()); 

/注册 的 解析 器 


BeanDefinitionParser parser = this.parsers.get(localName); 


if (parser == null) { 
parserContext.getReaderContext().fatal( 


"Cannot locate BeanDefinitionParser for element [" + localName + 
"|", element); 


} 


return parser; 


} 
而 对 于 parse 方 法 的 处 理 : 


public final BeanDefinition parse(Element element, ParserContext 
parserContext) { 


AbstractBeanDefinition definition = parseInternal(element, 
parserContext); 


if (definition != null && !parserContext.isNested()) { 
try { 


String id = resolveld(element, definition, parserContext); 
if (IStringUtils.hasText(id)) { 
parserContext.getReaderContext().error( 
"Id is required for element "" + parserContext. 
getDelegate().getLocalName(element) 


* " when used as a top-level tag", element); 


} 


String[] aliases = new String[0]; 


String name = element.getAttribut(NAME ATTRIBUTE); 
if (StringUtils.hasLength(name)) { 
aliases = 


StringUtils.trimArrayElements(StringUtils.commaDelimitedListToStringArra 


/将 AbstractBeanDefinition 转 换 为 BeanDefinitionHolder 并 注册 
BeanDefinitionHolder holder = new 
BeanDefinitionHolder(definition, id, 
aliases); 
registerBeanDefinition(holder, parserContext.getRegistry()); 
if (shouldFireEvents()) 1 
[fi SEES the Ur i WU] GE TT RP 
BeanComponentDefinition componentDefinition = new 
BeanComponent 
Definition(holder); 
postProcessComponentDefinition(componentDefinition); 


parserContext.registerComponent(componentDefinition); 


j 
catch (BeanDefinitionStoreException ex) { 
parserContext.getReaderContext().error(ex.getMessage(), 
element); 


return null; 


} 
return definition; 
} 
虽说 是 对 上 自 定 义 配 置 文件 的 解析 ， 但 是 ， 我 们 可 以 看 到 ， 在 这 个 函 
数 中 大 部 分 的 代码 是 用 来 处 理 将 解析 后 的 AbstractBeanDefinition 转 化 为 
BeanDefinitionHolder 并 注册 的 功能 ， 而 真正 去 做 解析 的 事情 委托 给 了 郴 
数 parseInternal， 正 是 这 名 代码 调用 了 我 们 目 定 义 的 解析 函数 。 


在 parseInternal 中 并 不 是 直接 调用 自 定 义 的 doParse 函 数 ， 而 是 进行 
了 一 系列 的 数据 准备 ， 包 括 对 beanClass、scope、lazyInit 等 属性 的 准 
备 。 
protected final AbstractBeanDefinition parseInternal(Element element， 
ParserContext 
parserContext) { 
BeanDefinitionBuilder builder = 
BeanDefinitionBuilder.genericBeanDefinition(); 
String parentName = getParentName(element); 
if (parentName != null) { 
builder.getRawBeanDefinition().setParentName(parentName); 
} 
// 获 取 自 定义 标签 中 的 class， 此 时 会 调用 自 定义 解析 器 如 
UserBeanDefinitionParser 中 的 getBeanClass 
方法 3 
Class<?> beanClass = getBeanClass(element); 
if (beanClass != null) { 
builder.getRawBeanDefinition().setBeanClass(beanClass); 
} 
else { 
/ 若 子 类 没有 重 写 getBeanClass 方 法 则 尝试 检查 子 类 是 否 重 写 
getBeanClassName 方 法 
String beanClassName = getBeanClassName(element); 


if (beanClassName != null) { 











builder.getRawBeanDefinition().setBeanClassName(beanClassName); 


} 


builder.getRawBeanDefinition().setSource(parserContext.extractSource(elem¢ 
if (parserContext.isNested()) { 
/和 看 存在 父 类 则 使 用 父 类 的 scope 属 性 


builder.setScope(parserContext.getContainingBeanDefinition().getScope()); 
} 
if (parserContext.isDefaultLazylInit()) { 
// Default-lazy-init applies to custom bean definitions as well. 
/配置 延迟 加 载 
builder.setLazyInit(true); 
} 
/调用 子 类 重 写 的 doParse 方 法 进行 解析 
doParse(element, parserContext, builder); 
return builder.getBeanDefinition(); 
j 
protected void doParse(Element element, ParserContext parserContext, 
BeanDefinition 
Builder builder) 1 
doParse(element, builder); 
j 
回顾 一 下 全 部 的 自 定义 标签 处 理 过 程 ， 虽 然 在 实例 中 我 们 定义 
UserBeanDefinitionParser， 但 是 在 其 中 我 们 只 是 做 了 与 自己 业务 逻辑 相 
关 的 部 分 。 不 过 我 们 没 做 但 是 并 不 代表 没有 ， 在 这 个 处 理 过 程 中 同样 也 
是 按照 Spring 中 默认 标签 的 处 理 方 式 进行 ， 包 括 创建 BeanDefinition 以 及 
进行 相应 默认 属性 的 设置 ， 对 于 这 些 工作 Spring 都 默默 地 帮 我 们 实现 














了 ， 只 是 暴露 出 一 些 接 口 来 供用 户 实 现 个 性 化 的 业务 。 通 过 对 本 章 的 了 
解 ， 相 信 读 者 对 Spring 中 自 定义 标签 的 使 用 以 及 在 解析 自 定义 标签 过 程 
中 Spring 为 我 们 做 了 哪些 工作 会 有 一 个 全 面 的 了 解 。 到 此 为 止 我 们 已 经 
完成 了 Spring 中 全 部 的 解析 工作 ， 也 就 是 说 到 现在 为 止 我 们 已 经 理解 了 

Spring 将 bean 从 配置 文件 到 加 载 到 内 存 中 的 全 过 程 ， 而 接 下 来 的 任务 便 

是 如 何 使 用 这 些 bean， 下 一 章 将 介绍 bean 的 加 载 。 


235 bean 


经 过 前 面 的 分 析 ， 我 们 终于 结束 了 对 XML 配 置 文件 的 解析 ， 接 下 
来 将 会 面临 更 大 的 挑战 ， 就 是 对 bean 加 载 的 探索 。bean 加 载 的 功能 实现 
远 比 bean 的 解析 要 复杂 得 多 ， 同 样 ， 我 们 还 是 以 本 书 开篇 的 示例 为 基 
础 ， 对 于 加 载 bean 的 功能 ， 在 Spring 中 的 调用 方式 为 : 
MyTestBean bean=(MyTestBean) bf.getBean("myTestBean") 
这 名 代码 实现 了 什么 样 的 功能 呢 ? 我 们 可 以 先 快速 体验 一 下 Spring 
中 代码 是 如 何 实现 的 。 
public Object getBean(String name) throws BeansException { 
return doGetBean(name, null, null, false); 
} 
protected <T> T doGetBean( 
final String name, final Class<T> requiredType, final Object[] args, 
boolean 
typeCheckOnly) throws BeansException 1 
/提取 对 应 的 beanName 
final String beanName = transformedBeanName(name); 
Object bean; 
/* 








* 检查 绥 存 中 或 者 实例 工厂 中 是 否 有 对 应 的 实例 

* 为 什么 首先 会 使 用 这 段 代 码 呢 ， 

* 因为 在 创建 单 例 bean 的 时 候 会 存在 依赖 注入 的 情况 ， 而 在 创 
建 依赖 的 时 候 为 了 避免 循环 依赖 ， 

* Spring 创建 bean 的 原则 是 不 等 bean 创 建 完 成 就 会 将 创建 bean 的 
ObjectFactory 提 早上 曝光 

* 也 就 是 将 ObjectFactory 加 入 到 缓存 中 ， 一 旦 下 个 bean 创 建 时 
候 需 要 依赖 上 个 bean 则 直接 使 用 

ObjectFactory 

"I 

/直接 尝试 从 缓存 获取 或 者 singletonFactories 中 的 ObjectFactory 中 





Object sharedInstance = getSingleton(beanName); 
if (sharedInstance != null && args == null) { 
if (logger.isDebugEnabled()) { 
if (isSingletonCurrentlyInCreation(beanName)) { 
logger.debug(" Returning eagerly cached instance of singleton 
bean 
" + beanName + 
"that is not fully initialized yet - a consequence of 
a circular reference"); 
} 
else { 
beanName + """); 


logger.debug(" Returning cached instance of singleton bean "' 


} 
/返回 对 应 的 实例 ， 有 时 候 存 在 诸如 BeanFactory 的 情况 并 不 是 直 
接 返 回 实例 本 映 而 是 返回 指定 方法 返回 的 实例 


bean = getObjectForBeanInstance(sharedInstance, name, 








beanName, null); 
jelse 1 

/只 有 在 单 例 情况 才 会 符 试 解决 循环 依赖 ， 原 型 模式 情况 下 ， 
OUR AF EE 

WA 中 有 B 的 属性 ，B 中 有 A 的 属性 ， 那 么 当 依赖 注入 的 时 候 ， 
就 会 产生 当 A 还 未 创建 完 的 时 候 因为 

// 对 于 B 的 创建 再 次 返回 创建 A， 造 成 循环 依赖 ， 也 就 是 下 面 的 
情况 

WisPrototypeCurrentlyInCreation(beanName) 为 true 

if (isPrototypeCurrentlyInCreation(beanName)) { 

throw new BeanCurrentlyInCreationException(beanName); 

} 

BeanFactory parentBeanFactory = getParentBeanFactory(); 

/如 果 beanDefinitionMap 中 也 就 是 在 所 有 已 经 加 载 的 类 中 不 包 
括 beanName 则 尝试 从 

parentBeanFactory 中 检测 

if (parentBeanFactory != null && 
!containsBeanDefinition(beanName)) { 

String nameToLookup = originalBeanName(name); 
/递归 到 BeanFactory 中 寻找 
if (args != null) { 


return (T) parentBeanFactory.getBean(nameToLookup, args); 


else { 
return parentBeanFactory.getBean(nameToLookup, 
requiredType); 
} 
} 
// 如 果 不 是 仅仅 做 类 型 检查 则 是 创建 bean， 这 里 要 进行 记录 
if (!typeCheckOnly) { 
markBeanAsCreated(beanName); 
j 
/将 存储 XML 配置 文件 的 GernericBeanDefinition 转 换 为 
RootBeanDefinition， 如 果 指 
定 BeanName 是 子 Bean 的 话 同 时 会 合并 父 类 的 相关 属性 
final RootBeanDefinition mbd = 
getMergedLocalBeanDefinition(beanName); 
checkMergedBeanDefinition(mbd, beanName, args); 
String] dependsOn = mbd.getDependsOn(); 
/各 存在 依赖 则 需要 递归 实例 化 依赖 的 bean 
if (dependsOn != null) { 
for (String dependsOnBean : dependsOn) { 
getBean(dependsOnBean); 
/ 绥 存 依赖 调用 


registerDependentBean(dependsOnBean, beanName); 


} 
/实例 化 依赖 的 bean 后 便 可 以 实例 化 mbd 本 号 了 
//singleton 模 式 的 创建 

if (mbd.isSingleton()) { 


sharedInstance = getSingleton(beanName, new 
ObjectFactory<Object>() { 

public Object getObject() throws BeansException { 

try { 
return createBean(beanName, mbd, args); 

} 

catch (BeansException ex) { 
destroySingleton(beanName); 


throw ex; 


} 
y 
bean = getObjectForBeanInstance(sharedInstance, name, 
beanName, mbd); 
Jelse if (mbd.isPrototype()) 1 
//prototype 模 式 的 创建 (new) 
Object prototypeInstance = null; 
try { 
beforePrototypeCreation(beanName); 
prototypeInstance = createBean(beanName, mbd, args); 
} 
finally { 
afterPrototypeCreation(beanName); 
} 
bean = getObjectForBeanInstance(prototypeInstance, name, 
beanName, mbd); 
}else { 


/指定 的 scope 上 实例 化 bean 
String scopeName = mbd.getScope(); 
final Scope scope = this.scopes.get(scopeName); 


if (scope == null) { 


throw new IllegalStateException("No Scope registered for scope 


+ scopeName + """); 


} 
try { 


Object scopedInstance = scope.get(beanName, new 
ObjectFactory<Object>() 1 


public Object getObject() throws BeansException 1 
beforePrototypeCreation(beanName); 
try 1 


return createBean(beanName, mbd, args); 


} 
finally { 


afterPrototypeCreation(beanName); 


} 
D; 


bean = getObjectForBeanInstance(scopedInstance, name, 
beanName, mbd); 


} 
catch (IllegalStateException ex) { 


throw new BeanCreationException(beanName, 
thread; " + 


"Scope " + scopeName + " is not active for the current 
"consider defining a scoped proxy for this bean if you 
intend to refer to it from a singleton", 


ex); 


/ 检 碍 需要 的 类 型 是 否 符合 bean 的 实际 类 型 
if (requiredType != null && bean != null && 
!requiredType.isAssignableFrom 
(bean.getClass())) { 
try { 
return getT'ypeConverter().convertIf Necessary(bean, 
requiredType); 
j 
catch (TypeMismatchException ex) { 
if (logger.isDebugEnabled()) { 


Tr 


logger.debug("Failed to convert bean "' + name + "to 
required type 
"+ 
ClassUtils.getQualifiedName(requiredType) + "]", ex); 
} 
throw new BeanNotOfRequiredTypeException(name, 
requiredType, bean. 
getClass()); 
} 


return (T) bean; 

} 

UA TRA E Ete a HOR bean 的 加 载 经 历 了 一 个 相当 复杂 的 过 
程 ， 其 中 涉及 各 种 各 样 的 考虑 。 相 信 读 者 细心 阅读 上 面 的 代码 ， 并 参照 
部 分 代码 注释 ， 是 可 以 粗略 地 了 解 整个 Spring 加 载 bean 的 过 程 。 对 于 加 
载 过 程 中 所 涉及 的 步骤 大 致 如 下 。 

(1) 转换 对 应 beanName。 

或 许 很 多 人 不 理解 转换 对 应 beanName 是 什么 意思 ， 传 入 的 参数 
name 不 就 是 beanName 吗 ? 其 实 不 是 ， 这 里 传 入 的 参数 可 能 是 别名 ， 也 
可 能 是 FactoryBean， 所 以 需要 进行 一 系列 的 解析 ， 这 些 解析 内 容 包 括 
如 下 内 容 。 

去 除 FactoryBean 的 修饰 符 ， 也 就 是 如 果 name="&aa"， 那 么 会 首先 
去 除 及 而 使 hIame="aa"。 

取 指 定 aliass 所 表示 的 最 终 beanName， 例 如 别名 A 指向 名 称 为 B 的 
bean 则 返回 B; 若 别 名 A 指 向 别名 B， 别 名 B 又 指向 名 称 为 C 的 bean 则 返回 
Co 











(2) ZWART PIRR 

单 例 在 Spring 的 同一 个 容器 内 只 会 被 创建 一 次 ， 后 续 再 获取 bean， 
就 直接 从 单 例 绥 存 中 获取 了 。 当 然 这 里 也 只 是 尝试 加 载 ， 首 先 尝试 从 绥 
存 中 加 载 ， 如 果 加 载 不 成 功 则 再 次 尝试 从 singletonFactories 中 加 载 。 
为 在 创建 单 例 bean 的 时 候 会 存在 依赖 注入 的 情况 ， 而 在 创建 依赖 的 时 候 
为 了 避免 循环 依赖 ， 在 Spring 中 创建 bean 的 原则 是 不 等 bean 创 建 完 成 就 
会 将 创建 bean 的 ObjectFactory 提 早上 曝光 加 入 到 绥 存 中 ， 一 旦 下 一 个 bean 
创建 时 候 需 要 依赖 上 一 个 bean 则 直接 使 用 ObjectFactory《〈 后 面 章节 会 对 
循环 依赖 重点 讲解 ) 。 

(3) bean 的 实例 化 。 

如 有 果 从 缓存 中 得 到 了 bean 的 原始 状态 ， 则 需要 对 bean 进 行 实例 化 。 











这 里 有 必要 强调 一 下 ， 绥 存 中 记录 的 只 是 最 原始 的 bean 状态 ， 并 不 一 定 
是 我 们 最 终 想 要 的 bean。 举 个 例子 ， 假 如 我 们 需要 对 工厂 bean 进 行 处 
理 ， 那 么 这 里 得 到 的 其 实 是 工厂 bean 的 初始 状态 ， 但 是 我 们 真正 需要 的 
是 工厂 bean 中 定义 的 factory-method 方 法 中 返回 的 bean， 而 
getObjectForBeanInstance 就 是 完成 这 个 工作 的 ， 后 续 会 详细 讲解 。 

(40 原型 模式 的 依赖 检查 。 

只 有 在 单 例 情况 下 才 会 答 试 解决 循环 依赖 ， 如 果 存 在 A 中 有 B 的 属 
性 ，B 中 有 A 的 属性 ， 那 么 当 依赖 注入 的 时 候 ， 束 会 产生 当 A 还 未 创建 完 
的 时 候 因 为 对 于 B 的 创建 再 次 返回 创建 A， 造 成 循环 依赖 ， 也 融 是 情 
况 : isPrototypeCurrentlyInCreation(beanName)J74| rtrue 








(5) 检测 parentBeanFactory。 

从 代码 上 看 ， 如 果 绥 存 没 有 数据 的 话 直接 转 到 父 类 工厂 上 去 加 载 
了 ， 这 是 为 什么 呢 ? 

可 能 读者 忽略 了 一 个 很 重要 的 判断 条 件 : parentBeanFactory != null 
&& !containsBean Definition (beanName), parentBeanFactory != null. 
parentBeanFactory 如 果 为 空 ， 则 其 他 一 切 都 是 浮云 ， 这 个 没什么 说 的 ， 
但 是 !containsBeanDefinition(beanName) 就 比较 重要 了 ， 它 是 在 检测 如 果 
当前 加 载 的 XML 配置 文件 中 不 包含 beanName 所 对 应 的 配置 ， 束 只 能 到 
parentBeanFactory 去 尝试 下 了 了， 然后 再 去 递归 的 调用 getBean 方 法 。 

(6) 将 存储 XML 配置 文件 的 GernericBeanDefinition 转 换 为 
RootBeanDefinition 。 

为 从 XML 配置 文件 中 读 取 到 的 Bean 信 息 是 存储 在 
GernericBeanDefinition 中 的 ， 但 是 所 有 的 Bean 后 续 处 理 都 是 针对 于 
RootBeanDefinition 的 ， 所 以 这 里 需要 进行 一 个 转换 ， 转 换 的 同时 如 果 
父 类 bean 不 为 空 的 话 ， 则 会 一 并 合并 父 类 的 属性 。 

C) 寻找 依赖 。 
因为 bean 的 初始 化 过 程 中 很 可 能 会 用 到 有 某 些 属性 ， 而 某 些 属性 很 





可 能 是 动态 配置 的 ， 并 且 配 置 成 依赖 于 其 他 的 bean， 那 么 这 个 时 候 束 有 
必要 先 加 载 依赖 的 bean， 所 以 ， 在 Spring 的 加 载 顺 寻 中 ， 在 初始 化 某 一 
个 bean 的 时 候 首 先 会 初始 化 这 个 bean 所 对 应 的 依赖 。 

(8) 针对 不 同 的 scope 进 行 bean 的 创建 。 

我 们 都 知道 ， 在 Spring 中 存在 着 不 同 的 scope， 其 中 默认 的 是 
singleton， 但 是 还 有 些 其 他 的 配置 诸如 prototype、request 之 类 的 。 在 这 
个 步骤 中 ，Spring 会 根据 不 同 的 配置 进行 不 同 的 初始 化 策略 。 

(9) 类 型 转换 。 

程序 到 这 里 返回 bean 后 已 经 基本 结束 了 ， 通 常 对 该 方法 的 调用 参数 
requiredType 是 为 空 的 ， 但 是 可 能 会 存在 这 样 的 情况 ， 返 回 的 bean 其 实 
是 个 String， 但 是 requiredType 却 传 入 Integer 类 型 ， 那 么 这 时 候 本 步骤 
就 会 起 作用 了 ， 它 的 功能 是 将 返回 的 bean 转 换 为 requiredType 所 指定 的 
类 型 。 当 然 ，String 转 换 为 Integer 是 最 简单 的 一 种 转换 ， 在 Spring 中 提供 
了 各 种 各 样 的 转换 器 ， 用 户 也 可 以 自己 扩展 转换 器 来 满足 需求 。 

经 过 上 面 的 步 又 后 bean 的 加 载 就 结束 了 ， 这 个 时 候 就 可 以 返回 我 们 
所 需要 的 bean 了， 图 5-1 直 观 地 反映 了 整个 过 程 。 其 中 最 重要 的 就 是 步 
又 (8) ， 针 对 不 同 的 scope 进 行 bean 的 创建 ， 你 会 看 到 各 种 常用 的 
Spring 特性 在 这 里 的 实现 。 

在 细 化 分 析 各 个 步骤 提供 的 功能 前 ， 我 们 有 必要 先 了 解 下 
FactoryBean 的 用 法 。 
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图 5-1 bean 的 获取 过 程 


5.1 FactoryBean 的 使 用 


一 般 情 况 下 ，Spring 通 过 反射 机 制 利用 bean 的 class 属 性 指定 实现 类 
来 实例 化 bean 。 在 某 些 情况 下 ， 实 例 化 bean 过 程 比较 复杂 ， 如 果 按 照 
传统 的 方式 ， 则 需要 在 <bean> 中 提供 大 量 的 配置 信息 ， 配 置 方式 的 灵活 
性 是 受 限 的 ， 这 时 采用 编码 的 方式 可 能 会 得 到 一 个 简单 的 方案 。Spring 
为 此 提供 了 一 个 org.Springframework.bean.factory.FactoryBean 的 工厂 类 
接口 ， 用 户 可 以 通过 实现 该 接口 定制 实例 化 bean 的 逻辑 。 
FactoryBean 接口 对 于 Spring 框架 来 说 占有 重要 的 地 位 ，Spring A 
吴 就 提供 了 70 多 个 FactoryBean 的 实现 。 它 们 隐藏 了 实例 化 一 些 复杂 
bean 的 细节 ， 给 上 层 应 用 市 来 了 便利 。 从 Spring 3.0 开 始 ， FactoryBean 
开始 文 持 泛 型 ， 即 接口 声明 改 为 FactoryBean<T> 的 形式 : 
package org.Springframework.beans.factory; 
public interface FactoryBean<T> { 
T getObject() throws Exception; 
Class<?> getObjectType(); 
boolean isSingleton(); 
} 
在 该 接口 中 还 定义 了 以 下 3 个 方法 。 
T getObject(): 返回 由 FactoryBean 创 建 的 bean 实例 ， 如 果 
isSingleton0 返 回 true, MIZKA C Spring Aas FPA IH s 
boolean isSingleton(): 返回 由 FactoryBean 创 建 的 bean 实例 的 作用 域 
是 singleton 还 是 prototype。 
Class<T> getObjectType(): 返回 FactoryBean 创 建 的 bean 类 型 , 
当 配 置 文件 中 <bean> 的 class 属 性 配置 的 实现 类 是 FactoryBean 时 ， 
通过 getBean() 方 法 返回 的 不 是 FactoryBean AY, rfj 
FactoryBean#getObject() 方 法 所 返回 的 对 象 ， 相 当 于 








FactoryBean#getObject(){t## f getBeanQZ; 7E .. PIO: 如 果 使 用 传统 方式 
配置 下 面 Car 的 <bean> 时 ，Car 的 每 个 属性 分 别 对 应 一 个 <property> 元 素 
标签 
public class Car { 
private int maxSpeed ; 
private String brand ; 
private double price ; 
//get/set 方 法 
} 
如 果 用 FactoryBean 的 方式 实现 就 会 灵活 一 些 ， 下 例 通 过 逗号 分 割 
符 的 方式 一 次 性 地 为 Car 的 所 有 属性 指 定 配置 值 ， 


public class CarFactoryBean implements FactoryBean<Car> { 





private String carInfo ; 

public Car getObject () throws Exception { 
Car car = new Car () ; 
String [] infos = carInfo .split ( "," ) ; 
car.setBrand (infos [ 0 J); 
car.setMaxSpeed ( Integer. valueOf ( infos [ 1 ])) ; 
car.setPrice ( Double. valueOf ( infos [ 2 ])) ; 
return Car; 

} 

public Class<Car> getObjectType () { 
return Car. class ; 

} 

public boolean isSingleton () { 


return false ; 


public String getCarInfo () { 
return this . carInfo ; 
} 
/ ZZE S A EFT BE fa E 
public void setCarInfo ( String carInfo ) { 


this . carInfo = carInfo; 


} 

有 了 这 个 CarFactoryBean 后 ， 束 可 以 在 配置 文件 中 使 用 下 面 这 种 上 自 
定义 的 配置 方式 配置 Car Bean 了 : 

<bean id="car" class="com.test.factorybean.CarFactoryBean" 
carInfo=" 超 级 跑车 ,400,2000000"/> 

当 调 用 getBean("car") 时 ，Spring 通过 反射 机 制 发 现 CarFactoryBean 
实现 了 FactoryBean 的 接口 ， 这 时 Spring 容器 束 调 用 接口 方法 
CarFactoryBean#getObject() 方 法 返回 。 如 果 和 希望 获取 CarFactoryBean 的 实 
例 ， 则 需要 在 使 用 getBean(beanName) 方法 时 在 beanName 前 显示 的 加 
上 "&" 前 级 ， 例 如 getBean("&car")。 


cus 
x. 


5.2 2 |bean 


jr 2H3TFactoryBeanff] His Ja, RATP VA. f fbean dR T o 
前 面 已 经 提 到 过 ， 单 例 在 Spring 的 同一 了 ae IR, 8 
FESR bean xe MIE Ze EPR, SPA UU Ae ea, Hox 
WM ZEE FINE, PAIS ARE eae A 因为 
在 创建 单 例 bean 的 时 候 会 存在 依赖 注入 的 情况 ， 而 在 创建 依赖 的 时 候 为 
了 避免 循环 依赖 ， Spring 创建 bean 的 原则 是 不 等 bean 创 建 完成 融会 将 创 
建 bean 的 ObjectFactory 提 早上 曝光 加 入 到 缓存 中 ， 一 旦 下 一 个 bean 创 建 时 





需要 依赖 上 个 bean， 则 直接 使 用 ObjectFactory。 
public Object getSingleton(String beanName) { 
/参数 true 设 置 标识 允许 早期 依赖 
return getSingleton(beanName, true); 
} 
protected Object getSingleton(String beanName, boolean 
allowEarlyReference) { 
// 检 查 缓存 中 是 否 存在 实例 
Object singletonObject = this.singletonObjects.get(beanName); 














if (singletonObject == null) { 
/如 果 为 空 ， 则 锁定 全 局 变量 并 进行 处 理 
synchronized (this.singletonObjects) { 
/如 果 此 bean 正 在 加 载 则 不 处 理 
singletonObject = this.earlySingletonObjects.get(beanName); 
if (singletonObject == null && allowEarlyReference) { 
// 当 某 些 方法 需要 提前 初始 化 的 时 候 则 会 调用 
addSingletonFactory 方法 将 对 应 
的 ObjectFactory 初 始 化 策略 存储 在 singletonFactories 
(beanName); 
ObjectFactory singletonFactory = this.singletonFactories.get 
if (singletonFactory != null) { 
/调用 预先 设 定 的 getObject 方 法 
singletonObject = singletonFactory.getObject(); 
/记录 在 缓存 中 ，earlySingletonObjects 和 
singletonFactories H. t 
this.earlySingletonObjects.put(beanName, 
singletonObject); 


this.singletonFactories.remove(beanName); 


} 
return (singletonObject != NULL_OBJECT ? singletonObject : null); 
} 
这 个 方法 因为 涉及 循环 依赖 的 检测 ， 以 及 涉及 很 多 变量 的 记录 存 
取 ， 所 以 让 很 多 读者 摸 不 着 头脑 。 这 个 方法 首先 尝试 从 singletonObjects 
里 面 获取 实例 ， 如 果 获 取 不 到 再 从 earlySingleton Objects 里 面 获取 ， 如 
果 还 获取 不 到 ， 再 尝试 从 singletonFactories 里 面 获取 beanName 对 应 的 
ObjectFactory， 然 后 调用 这 个 ObjectFactory 的 getObject 来 创建 bean， 
并 放 到 earlySingleton Objects 里 面 去 ， 并 且 从 singletonFacotories 里 面 
remove 折 这 个 ObjectFactory， 而 对 于 后 续 的 所 有 内 存 操作 都 只 为 了 循环 
依赖 检测 时 候 使 用 ， 也 就 是 在 alowEarlyReference 为 true 的 情况 下 才 会 使 
用 。 











里 涉及 用 于 存储 bean 的 不 同 的 map， 可 能 让 读者 感到 朋 溃 ， 人 简单 

解释 s Te 

singletonObjects: 用 于 保存 BeanName 和 创建 bean 实 例 之 间 的 关系 ， 
bean name --> bean instance。 

singletonFactories: 用 于 保存 BeanName 和 创建 bean 的 工厂 之 间 的 关 
系 ，bean name -->ObjectFactory。 

earlySingletonObjects: 也 是 保存 BeanName 和 创建 bean 实例 之 间 
的 关系 ， 与 singletonObjects 的 不 同 之 处 在 于 ， 当 一 个 单 例 bean 被 放 到 这 
里 面 后 ， 那 么 当 bean 还 在 创建 过 程 中 ， 就 可 以 通过 getBean 方 法 获取 到 
了 ， 其 目的 是 用 来 检测 循环 引用 。 

registeredSingletons: 用 来 保存 当前 所 有 已 注册 的 bean。 





5.3 从 bean 的 实例 中 获取 大 


在 getBean 方法 中 ，getObjectForBeanInstance 是 个 高 频率 使 用 的 方 
法 ， 无 论 是 从 绥 存 中 获得 bean 还 是 根据 不 同 的 scope 策 略 加 载 bean。 总 
之 ， 我 们 得 到 bean 的 实例 后 要 做 的 第 一 步 就 是 调用 这 个 方法 来 检测 一 下 
正确 性 ， 其 实 束 是 用 于 检测 当前 bean f FactoryBean 类 型 的 bean， 
如 果 是 ， 那 么 需要 调用 该 bean 对 应 的 FactoryBean 实 例 中 的 getObject() 作 
为 返回 值 。 

无 论 是 从 绥 存 中 获取 到 的 bean 还 是 通过 不 同 的 scope 策 略 加 载 的 bean 
都 只 是 最 原始 的 bean 状 态 ， 并 不 一 定 是 我 们 最 终 想 要 的 bean。 举 个 例 
子 ， 假 如 我 们 需要 对 工厂 bean 进 行 处 理 ， 那 么 这 里 得 到 的 其 实 是 工 广 
bean 的 初始 状态 ， 但 是 我 们 真正 需要 的 是 工厂 bean 中 定义 的 factory- 
method 方 法 中 返回 的 beaan， 而 getObjectForBeanInstance 方 法 就 是 完成 这 
ALAA 


protected Object getObjectForBeanInstance( 

















Object beanInstance, String name, String beanName, 
RootBeanDefinition mbd) { 
/ A8 rE Jnamezé L) R(E 2%) H.beanInstance XA zé 
FactoryBean 类 型 则 验证 不 通过 
if (BeanFactoryUtils.isFactoryDereference(name) && !(beanInstance 
instanceof 
FactoryBean)) { 
throw new 
BeanIsNotA FactoryException(transformedBeanName(name), beanInstance. 
getClass()); 


/现在 我 们 有 了 个 bean 的 实例 ， 这 个 实例 可 能 会 是 正常 的 bean 或 
者 是 FactoryBean 

/如 果 是 FactoryBean 我 们 使 用 它 创 建 实例 ， 但 是 如 果 用 户 想 要 直 
接 获 取 工厂 实例 而 不 是 工厂 的 

getObject 方 法 对 应 的 实例 那么 传 入 的 name 应 该 加 入 前 级 & 


让 (!(beanInstance instanceof FactoryBean) || BeanFactoryUtils. 











IsFactory 
Dereference(name)) { 
return beanInstance; 
} 
/加 载 FactoryBean 
Object object = null; 
if (mbd == null) { 
WAM Bee H bean 
object = getCachedObjectForFactoryBean(beanName); 
} 
if (object == null) { 
// 到 这 里 已 经 明确 知道 beanInstance 一 定 是 FactoryBean 类 型 
FactoryBean<?> factory = (FactoryBean<?>) beanInstance; 
/containsBeanDefinition 检 测 beanDefinitionMap 中 也 就 是 在 所 有 
己 经 加 载 的 类 中 检测 
是 否定 义 beanName 
if (mbd == null && containsBeanDefinition(beanName)) { 
/将 存储 XML 配置 文件 的 GernericBeanDefinition 转 换 为 
RootBeanDefinition, 
如 果 指 定 BeanName 是 子 Bean 的 话 同 时 会 合并 父 类 的 相关 属 
性 


mbd = getMergedLocalBeanDefinition(beanName); 
} 
IL FS jt H] P? se SCRI f] AS s DF EP AS ESO 
boolean synthetic = (mbd != null && mbd.isSynthetic()); 








object = getObjectFromFactoryBean(factory, beanName, 
!'synthetic); 
j 
return object; 
j 
从 上 面 的 代码 来 看 ， 其 实 这 个 方法 并 没有 什么 重要 的 信息 ， 大 多 是 
些 辅助 代码 以 及 一 些 功能 性 的 判断 ， 而 真正 的 核心 代码 却 委 托 给 了 
getObjectFromFactoryBean ， 我 们 来 看 看 getObjectForBeanInstance 中 的 所 
做 的 工作 。 
(1) 对 FactoryBean 正 确 性 的 验证 。 
(2) 对 非 FactoryBean 不 做 任何 处 理 。 
(3) 对 bean 进 行 转换 。 
(4) 将 从 Factory 中 解析 bean 的 工作 委托 给 
getObjectFromFactoryBean. 
protected Object getObjectFromFactory Bean(Factory Bean factory, 
String beanName, boolean 
shouldPostProcess) 1 
/如 果 是 单 例 模式 
if (factory.isSingleton() && containsSingleton(beanName)) { 
synchronized (getSingletonMutex()) { 
Object object = this.factoryBeanObjectCache.get(beanName); 
if (object == null) { 


shouldPostProcess); 


object = doGetObjectFromFactoryBean(factory, beanName, 
this.factory BeanObjectCache.put(beanName, (object != null ? 
object : 
NULL_OBJECT)); 
} 
return (object != NULL_OBJECT ? object : null); 


} 
else { 
return doGetObjectFromFactoryBean(factory, beanName, 
shouldPostProcess); 
j 
j 
很 遗憾 ， 在 这 个 代码 中 我 们 还 是 没有 看 到 想 要 看 到 的 代码 ， 在 这 个 
方法 里 只 做 了 一 件 事 情 ， 就 是 返回 的 bean 如 果 是 单 例 的 ， 那 就 必须 要 
保证 全 局 唯一 ， 同 时 ， 也 因为 是 单 例 的 ， 所 以 不 必 重 复 创 建 ， 可 以 使 用 
缓存 来 提高 性 能 ， 也 就 是 说 已 经 加 载 过 就 要 记录 下 来 以 便于 下 次 复 用 ， 
否则 的 话 就 直接 获取 了 。 
在 doGetObjectFromFactoryBean 方 法 中 我 们 终于 看 到 了 我 们 想 要 看 
到 的 方法 ， 也 就 是 object =factory.getObject0)， 是 的 ， 就 是 这 名 代码 ， 我 
们 的 历程 犹如 剥 洋葱 一 样 ， 一 层 一 层 的 直到 最 内 部 的 代码 实现 ， 虽 然 很 
简单 。 
private Object doGetObjectFromFactoryBean( 








final FactoryBean factory, final String beanName, final boolean 
shouldPostProcess) 
throws BeanCreationException { 


Object object; 


try { 
/需要 权限 验证 
if (System.getSecurityManager() != null) { 
AccessControlContext acc = getAccessControlContext(); 
try { 
Object>() { 
object = AccessController.doPrivileged(new 
PrivilegedExceptionAction< 
public Object run() throws Exception { 
return factory.getObject(); 
} 
}, acc); 
} 
catch (PrivilegedActionException pae) { 
throw pae.getException(); 


} 

else { 
/直接 调用 getObject 方 法 
object = factory.getObject(); 


} 
catch (FactoryBeanNotInitializedException ex) 1 
throw new BeanCurrentlyInCreationException(beanName, 
ex.toString()); 
j 
catch (Throwable ex) 1 


throw new BeanCreationException(beanName, "FactoryBean 
threw exception on 
object creation", ex); 
} 
if (object == null && isSingletonCurrentlyInCreation(beanName)) { 
throw new BeanCurrentlyInCreationException( 
beanName, "FactoryBean which is currently in creation returned 
null 
from getObject"); 
} 
if (object != null && shouldPostProcess) { 
try { 
/调用 ObjectFactory 的 后 处 理 器 
object = postProcessObjectFromFactoryBean(object, 
beanName); 
} 
catch (Throwable ex) { 
throw new BeanCreationException(beanName, "Post-processing 
of the 
FactoryBean's object failed", ex); 
} 
} 
return object; 
} 
上 面 我 们 已 经 讲述 了 FactoryBean 的 调用 方法 ， 如 果 bean 声 明 为 
FactoryBean 类 型 ， 则 当 提 取 bean 时 提取 的 并 不 是 FactoryBean， 而 是 
FactoryBean 中 对 应 的 getObject 方 法 返回 的 bean， 而 


doGetObjectFromFactoryBean 正 是 实现 这 个 功能 的 。 但 是 ， 我 们 看 到 在 
上 面 的 方法 中 除了 调用 object = factory.getObject0 得 到 我 们 想 要 的 结果 
后 并 没有 直接 返回 ， 而 是 接 下 来 又 做 了 些 后 处 理 的 操作 ， 这 个 又 是 做 什 
么 用 的 呢 ? 于 是 我 们 跟踪 进入 AbstractAutowireCapableBeanFactory 类 的 
postProcessObjectFromFactoryBean 方 法 : 








AbstractAutowireCapableBeanFactory.java 
protected Object postProcessObjectFromFactoryBean(Object object, 
String beanName) { 
return applyBeanPostProcessorsA fterInitialization(object, 
beanName); 
} 
public Object applyBeanPostProcessorsA fterInitialization(Object 
existingBean, String beanName) 
throws BeansException { 
Object result = existingBean; 
for (BeanPostProcessor beanProcessor : getBeanPostProcessors()) { 
result = beanProcessor.postProcessA fterInitialization(result, 
beanName); 
if (result == null) { 


return result; 


} 
return result; 
} 
e iE 才 多 接触 ， 后 续 草 节 会 使 用 大 量 篇 幅 
介绍 ， 这 里 ， 我 们 只 需 了 解 在 Spring 获取 bean 的 规则 中 有 这 样 一 条 :， JS 
可 能 保证 所 有 bean 初 始 化 后 都 会 调用 注册 的 BeanPostProcessor 的 





Jl 


postProcessAfterInitialization 方法 进行 处 理 ， 在 实际 开发 过 程 中 大 可 以 针 
对 此 特性 设计 目 己 的 业务 逻辑 。 


5.4 3 AY EUR 


之 前 我 们 讲解 了 从 缓存 中 获取 单 例 的 过 程 ， 那 么 ， 如 果 绥 存 中 不 存 
在 已 经 加 载 的 单 例 bean 就 需要 从 头 开始 bean 的 加 载 过 程 了 ， 而 Spring 中 
使 用 getSingleton 的 重 载 方法 实现 bean 的 加 载 过 程 。 
public Object getSingleton(String beanName, ObjectFactory 
singletonFactory) { 
Assert.notNull(beanName, "beanName' must not be null"); 
/全 局 变量 需要 同步 
synchronized (this.singletonObjects) { 
/首先 检查 对 应 的 bean 是 人 否 已 经 加 载 过 ， 因 为 singleton 模 式 其 实 
就 是 复 用 以 创建 的 bean， 所 
以 这 一 步 是 必须 的 
Object singletonObject = this.singletonObjects.get(beanName); 
// 如 果 为 空 才 可 以 进行 singleto 的 bean 的 初始 化 
if (singletonObject == null) { 








if (this.singletonsCurrentlyInDestruction) { 
throw new BeanCreationNotAllowedException(beanName, 
"Singleton bean creation not allowed while the singletons 
of this factory are in destruction " + 
"(Do not request a bean from a BeanFactory in a destroy 
method implementation! )"); 

了 

if (logger.isDebugEnabled()) { 


logger.debug("Creating shared instance of singleton bean ™ + 
beanName + """); 
} 
beforeSingletonCreation(beanName); 
boolean recordSuppressedExceptions = 
(this.suppressedExceptions == null); 
if (recordSuppressedExceptions) { 
this.suppressedExceptions = new LinkedHashSet<Exception> 
0; 
} 
try { 
/初始 化 bean 
singletonObject = singletonFactory.getObject(); 
} 
catch (BeanCreationException ex) { 
if (recordSuppressedExceptions) { 
for (Exception suppressedException : 
this.suppressedExceptions) { 


ex.addRelatedCause(suppressedException); 


} 
throw ex; 
} 
finally { 
if (recordSuppressedExceptions) { 


this.suppressedExceptions = null; 


afterSingletonCreation(beanName); 


} 
/加 入 缓存 
addSingleton(beanName, singletonObject); 
} 
return (singletonObject != NULL OBJECT ? singletonObject : 
null); 
j 
j 


上 述 代码 中 其 实 是 使 用 了 回调 方法 ， 使 得 程序 可 以 在 单 例 创建 的 前 
后 做 一 些 准备 及 处 理 操作 ， 而 真正 的 获取 单 例 bean 的 方法 其 实 并 不 是 在 
此 方法 中 实现 的 ， 其 实现 逻辑 是 在 ObjectFactory 类 型 的 实例 
singletonFactory 中 实现 的 。 而 这 些 准 备 及 处 理 操作 包括 如 下 内 容 。 
(1) MARR EA CES. 
(2) AWA Ma, WicdstbeanNamefly IEE MBIKAS . 
(3) 加 载 单 例 前 记录 加 载 状态 。 
可 能 你 会 觉得 beforeSingletonCreation 方 法 是 个 空 实 现 ， 里 面 没 有 任 
何 逻 辑 ， 但 其 实 不 是 ， 这 个 函数 中 做 了 一 个 很 重要 的 操作 :记录 加 载 状 
态 ， 也 就 是 通过 this.singletonsCurrentlyIn Creation.add(beanName) 将 当前 
正 要 创建 的 bean 记 录 在 缓存 中 ， 这 样 便 可 以 对 循环 依赖 进行 检测 。 


protected void beforeSingletonCreation(String beanName) { 














if (!this.inCreationCheckExclusions.contains(beanName) && 
!Ithis.singletons 
CurrentlyInCreation.add(beanName)) 1 


throw new BeanCurrentlyInCreationException(beanName); 


(4) 通过 调用 参数 传 入 的 ObjectFactory 的 个 体 Object 方法 实例 化 
bean 。 
(50 加 载 单 例 后 的 处 理 方法 调用 。 
同步 骤 (3) 的 记录 加 载 状态 相似 ， 当 bean 加 载 结束 后 需要 移 除 组 
存 中 对 该 bean 的 正在 加 载 状态 的 记录 。 
protected void afterSingletonCreation(String beanName) { 
if (!this.inCreationCheckExclusions.contains(beanName) && 
Ithis.singletons 
CurrentlyInCreation.remove(beanName)) 1 
throw new IllegalStateException(" Singleton ' + beanName + ” 
isn't currently 


in creation"); 


} 
(6) 将 结果 记录 至 缓存 并 删除 加 载 bean 过 程 中 所 记录 的 各 种 辅助 
状态 。 


protected void addSingleton(String beanName, Object singletonObject) 


{ 
synchronized (this.singletonObjects) { 
this.singletonObjects.put(beanName, (singletonObject != null ? 
singletonObject : 


NULL_OBJECT)); 
this.singletonFactories.remove(beanName); 
this.earlySingletonObjects.remove(beanName); 


this.registeredSingletons.add(beanName); 


(7) 返回 处 理 结果 。 
虽然 我 们 已 经 从 外 部 了 解 了 加 载 bean 的 逻辑 架构 ， 但 现在 我 们 还 并 
没有 开始 对 bean 加 载 功能 的 探索 ， 之 前 提 到 过 ， bean 的 加 载 逻辑 其 实 
是 在 传 入 的 ObjectFactory 类 型 的 参数 singletonFactory 中 定义 的 ， 我 们 反 
推 参数 的 获取 ， 得 到 如 下 代码 : 
sharedInstance = getSingleton(beanName, new ObjectFactory<Object> 
0 t 
public Object getObject() throws BeansException 1 
try { 
return createBean(beanName, mbd, args); 
j 
catch (BeansException ex) 1 
destroySingleton(beanName); 


throw ex; 


} 
y 
ObjectFactory 的 核心 部 分 其 实 只 是 调用 了 createBean 的 方法 ， 所 以 我 
们 还 需要 到 createBean 方 法 中 追寻 真理 。 


5.5 准备 创建 bean 


我 们 不 可 能 指望 在 一 个 函数 中 完成 一 个 复杂 的 逻辑 ， 而 且 我 们 跟踪 
了 这 么 多 Spring 代 人 码 ， 经 历 了 这 么 多 函数 ， 或 多 或 少 也 发 现 了 一 些 规 
律 : 一 个 真正 干 活 的 函数 其 实 是 以 do 开头 的 ， 比 如 
doGetObjectFromFactoryBean; 而 给 我 们 错觉 的 函数 ， 比 如 
getObjectFromFactoryBean， 其 实 只 是 从 全 局 角度 去 做 些 统筹 的 工作 。 这 


个 规则 对 于 createBean 也 不 例外 ， 那 么 让 我 们 看 看 在 createBean 函 数 中 做 
了 哪些 准备 工作 。 
protected Object createBean(final String beanName, final 
RootBeanDefinition mbd, final 
Object[] args) throws BeanCreationException { 
if (logger.isDebugEnabled()) { 
logger.debug(" Creating instance of bean " + beanName + """); 
j 
/锁定 class, 根 据 设 置 的 class 属 性 或 者 根据 className 来 解析 Class 
resolveBeanClass(mbd, beanName); 
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try 1 
mbd.prepareMethodOverrides(); 
} 
catch (BeanDefinitionValidationException ex) { 
throw new 
BeanDefinitionStoreException(mbd.getResourceDescription(), 
beanName, "Validation of method overrides failed", ex); 
} 


try { 
/给 BeanPostProcessors 一 个 机 会 来 返回 代理 来 奉 代 真正 的 实例 


Object bean = resolveBeforeInstantiation(beanName, mbd); 
if (bean != null) { 


return bean; 


} 
catch (Throwable ex) { 


throw new BeanCreationException(mbd.getResourceDescription(), 
beanName, 
"BeanPostProcessor before instantiation of bean failed", ex); 
} 
Object beanInstance = doCreateBean(beanName, mbd, args); 
if (logger.isDebugEnabled()) { 


logger.debug("Finished creating instance of bean " + beanName + 


return beanInstance; 

} 

从 代码 中 我 们 可 以 总 结 出 函数 完成 的 具体 步骤 及 功能 。 

(1) 根据 设置 的 class 属 性 或 者 根据 className 来 解析 Class。 
(2) 对 override 属 性 进行 标记 及 验证 。 

很 多 读者 可 能 会 不 知道 这 个 方法 的 作用 ， 因 为 在 Spring 的 配置 里 面 
根本 就 没有 诸如 override-method 之 类 的 配置 ， 那 么 这 个 方法 到 底 是 干 什 
么 用 的 呢 ? 

其 实在 Spring 中 确实 没有 override-method 这 样 的 配置 ， 但 是 如 果 
读 过 前 面 的 部 分 ， 可 能 会 有 所 发 现 ， 在 Spring 配置 中 是 存在 lookup- 
method 和 replace-method 的 ， 而 这 两 个 配置 的 加 载 其 实 就 是 将 配置 统一 
存放 在 BeanDefinition 中 的 methodOverrides 属 性 里 ， 而 这 个 函数 的 操作 其 
实 也 就 是 针对 于 这 两 个 配置 的 。 

(3) 应 用 初始 化 前 的 后 处 理 器 ， 解 析 指 定 bean 是 否 存 在 初始 化 前 
的 短路 操作 。 
(4) 创建 bean。 
我 们 首先 查看 下 对 override 属 性 标记 及 验证 的 逻辑 实现 。 





5.5.1 处 理 ovverride 属 性 


查看 源码 中 AbstractBeanDefinition 类 的 prepareMethodOverrides 方 
法 : 
public void prepareMethodOverrides() throws 
BeanDefinitionValidationException { 
// Check that lookup methods exists. 
MethodOverrides methodOverrides = getMethodOverrides(); 
if (ImethodOverrides.isEmpty()) { 
for (MethodOverride mo : methodOverrides.getOverrides()) { 
prepareMethodOverride(mo); 


} 
protected void prepareMethodOverride(MethodOverride mo) throws 
BeanDefinition ValidationException 1 
/获取 对 应 类 中 对 应 方法 名 的 个 数 
int count = ClassUtils.getMethodCountForName(getBeanClass(), 
mo.getMethodName()); 
if (count == 0) { 
throw new BeanDefinition ValidationException( 
"Invalid method override: no method with name ™ + 
mo.getMethodName() + 
" on class [" + getBeanClassName() + "]"); 
} 
else if (count == 1) { 
/标记 MethodOverride 暂 未 被 敌 盖 ， 避 免 参数 类 型 检查 的 开 


销 。 
mo.setOverloaded(false); 
} 

} 

通过 以 上 两 个 函数 的 代码 你 能 体会 到 它 所 要 实现 的 功能 吗 ? 之 前 反 
复 提 到 过 ， 在 Spring 配 置 中 存在 lookup-method 和 replace-method 两 个 配置 
功能 ， 而 这 两 个 配置 的 加 载 其 实 就 是 将 配置 统一 存放 在 BeanDefinition 中 
的 methodOverrides 属 性 里 ， 这 两 个 功能 实现 原理 其 实 是 在 bean 实 例 化 的 
时 候 如 果 检 测 到 存在 methodOverrides 属 性 ， 会 动态 地 为 当前 bean 生 成 代 
理 并 使 用 对 应 的 拦截 器 为 bean 做 增强 处 理 ， 相 关 逻 辑 实现 在 bean 的 实例 
化 部 分 详细 介绍 。 

但 是 ， 这 里 要 提 到 的 是 ， 对 于 方法 的 匹配 来 讲 ， 如 果 一 个 类 中 存在 
若干 个 重 载 方法 ， 那 么 ， 在 函数 调用 及 增强 的 时 候 还 需要 根据 参数 类 型 
进行 匹配， 来 最 终 确认 当前 调用 的 到 底 是 哪个 函数 。 但 是 ，Spring 将 一 
部 分 匹配 工作 在 这 里 完成 了 ， 如 果 当 前 类 中 的 方法 只 有 一 个 ， 那 么 就 设 
置 重 载 该 方法 没有 被 重 载 ， 这 样 在 后 续 调 用 的 时 候 便 可 以 直接 使 用 找到 
的 方法 ， 而 不 需要 进行 方法 的 参数 匹配 验证 了 ， 而 且 还 可 以 提前 对 方法 
存在 性 进行 验证 ， 正 可 谓 一 箭 双 讷 。 

5.5.2 实例 化 的 前 置 处 


在 真正 调用 doCreate 方 法 创建 bean 的 实例 前 使 用 了 这 样 一 个 方法 
resolveBeforeInstantiation (beanName, mbd) 对 BeanDefinigiton 中 的 属性 做 
些 前 置 处 理 。 当 然 ， 无 论 其 中 是 否 有 相应 的 逻辑 实现 我 们 都 可 以 理解 ， 
因为 真正 逻辑 实现 前 后 留 有 处 理 函 数 也 是 可 扩展 的 一 种 体现 ， 但 是 ， 这 
并 不 是 最 重要 的 ， 在 函数 中 还 提供 了 一 个 短路 判断 ， 这 才 是 最 为 关键 的 
HAT o 


if (bean != null) 1 



































ng 


return bean; 
} 
当 经 过 前 置 处 理 后 返回 的 结果 如 果 不 为 空 ， 那 么 会 直接 略 过 后 续 的 
Bean 的 创建 而 直接 返回 结果 。 这 一 特性 虽然 很 容易 被 忽略 ， 但 是 却 起 
着 至 关 重 要 的 作用 ， 我 们 熟知 的 AOP 功能 就 是 基于 这 里 的 判断 的 。 


protected Object resolveBeforeInstantiation(String beanName, 





RootBeanDefinition mbd) { 
Object bean = null; 
// 如 果 尚 未 被 解析 
if (!Boolean.FALSE.equals(mbd.beforeInstantiationResolved)) { 
// Make sure bean class is actually resolved at this point. 
if (mbd.hasBeanClass() && !mbd.isSynthetic() && 
hasInstantiationAware 
BeanPostProcessors()) { 
bean = 
applyBeanPostProcessorsBeforeInstantiation(mbd.getBeanClass(), 
beanName); 
if (bean != null) { 
bean = applyBeanPostProcessorsA fterInitialization(bean, 
beanName); 
j 
j 
mbd.beforeInstantiationResolved = (bean !- null); 
j 
return bean; 
j 
此 方法 中 最 吸引 我 们 的 无 疑 是 两 个 方法 


applyBeanPostProcessorsBeforeInstantiation 以 及 
applyBeanPostProcessorsAfterInitialization。 两 个 方法 实现 的 非常 简单 ， 
无 非 是 对 后 处 理 器 中 的 所 有 InstantiationAwareBeanPostProcessor 类 型 的 
后 处 理 器 进行 postProcessBeforeInstantiation 方 法 和 BeanPostProcessor 的 
postProcessAfterInitialization 方 法 的 调用 。 

1. 实例 化 前 的 后 处 理 器 应 用 

bean 的 实例 化 前 调用 ， 也 就 是 将 AbsractBeanDefinition 转 换 为 
BeanWrapper 前 的 处 理 。 给 子 类 一 个 修改 BeanDefinition 的 机 会 ， 也 就 是 
说 当 程 序 经 过 这 个 方法 后 ，bean 可 能 已 经 不 是 我 们 认为 的 bean 了， 而 是 
Te a Acs 也 可 能 
是 通过 其 它 技 术 生 成 的 。 这 在 第 7 章 中 会 详细 介绍 ， 我 们 只 需要 知道 
在 bean 的 实例 化 前 会 调用 后 处 理 器 的 E à 


protected Object applyBeanPostProcessorsBeforeInstantiation(Class 











beanClass, String beanName) 
throws BeansException 1 
for (BeanPostProcessor bp : getBeanPostProcessors()) 1 
if (bp instanceof InstantiationA wareBeanPostProcessor) 1 

InstantiationA wareBeanPostProcessor ibp = (Instantiation 
AwareBean 

PostProcessor) bp; 

Object result = ibp.postProcessBeforeInstantiation(beanClass, 
beanName); 

if (result != null) 1 


return result; 


return null; 

} 

2. SCAM JG KI Jes ETHER IN H] 

在 讲解 从 缓存 中 获取 单 例 bean 的 时 候 就 提 到 过 ，Spring 中 的 规则 是 
在 bean 的 初始 化 后 尽 可 能 保证 将 注册 的 后 处 理 喜 的 
postProcessAfterInitialization 方 法 应 用 到 该 bean 中 ， 因 为 如 果 返 回 的 bean 
不 为 室 ， 那 么 便 不 会 再 次 经 历 普通 bean 的 创建 过 程 ， 所 以 只 能 在 这 里 应 
用 后 处 理 器 的 postProcessAfterInitialization 方 法 。 

public Object apply BeanPostProcessorsA fterInitialization(Object 








existingBean, String beanName) 
throws BeansException 1 
Object result = existingBean; 
for (BeanPostProcessor beanProcessor : getBeanPostProcessors()) 1 
result = beanProcessor.postProcessA fterInitialization(result, 
beanName); 
if (result == null) { 


return result; 


} 


return result; 


5.6 循环 依赖 


实例 化 bean 是 一 个 非常 复杂 的 过 程 ， 而 其 中 最 比较 难以 理解 的 吏 
是 对 循环 依赖 的 解决 ， 不 定之 前 读者 有 没有 对 循环 依赖 方面 的 研究 ， 这 
里 有 必要 先 对 此 知识 点 稍 作 回顾 。 


5.6.1 什么 是 循环 依赖 


循环 依赖 就 是 循环 引用 ， 就 是 两 个 或 多 个 bean 相互 之 间 的 持 有 对 
方 ， 比 如 CircleA 引用 CircleB，CircleB 引 用 CircleC，CircleC 引 用 
CircleA， 则 它们 最 终 反 映 为 一 个 环 。 此 处 不 是 循环 调用 ， 循 环 调 用 是 方 


法 之 间 的 环 调 用 ， 如 图 5-2 所 示 。 
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图 5-2 循环 依赖 


循环 调用 是 无 法 解决 的 ， 除 非 有 终结 条 件 ， 否 则 就 是 死 循环 ， 最 终 


导致 内 存 溢出 错误 。 
5.6.2 Spring 如 何 解 决 和 
Spring 容 峰 循环 依赖 包括 构造 堪 循环 依赖 和 setter 循 环 依赖 ， 那 

Spring 容 堪 如 何 解雇 循环 依赖 呢 ? 首先 让 我 们 来 定义 循环 引用 类 : 


NAR EM 


public class TestA { 
private TestB testB; 


public void a() { 

testB.b(); 
j 
public TestB getTestB() 1 

return testB; 
j 
public void setTestB(TestB testB) { 

this.testB = testB; 


j 
public class TestB 1 
private TestC testC; 
public void b() 1 
testC.c(); 
j 
public TestC getTestC() 1 
return testC; 
j 
public void setTestC(TestC testC) { 
this.testC = testC; 


j 
public class TestC 1 
private TestA testA; 
public void c() 1 
testA.a(); 


public TestA getTestA() { 
return testA; 

} 

public void setTestA(TestA testA) { 
this.testA = testA; 


} 

在 Spring 中 将 循环 依赖 的 处 理 分 成 了 3 种 情况 。 

1. 构造 器 循环 依赖 

表示 通过 构造 器 注入 构成 的 循环 依赖 ， 此 依赖 是 无 法 解决 的 ， 只 能 
抛 出 BeanCurrentlyIn CreationException 异 常 表 示 循 环 依赖 。 

如 在 创建 TestA 类 时 ， 构 造 器 需要 TestB 类 ， 那 将 去 创建 TestB， 在 
创建 TestB 类 时 又 发 现 需 要 TestC 类 ， 则 又 去 创建 TestC， 最 终 在 创建 
TestC 时 发 现 又 需要 TestA， 从 而 形成 一 个 环 ， 没 办 法 创建 。 

Spring 容器 将 每 一 个 正在 创建 的 bean 标 识 符 放 在 一 个 “当前 创建 bean 
池 ?” 中 ，bean 标 识 符 在 创建 过 程 中 将 一 直 保 持 在 这 个 池 中 ， 因 此 如 有 果 在 
创建 bean 过 程 中 发 现 上 自己 已 经 在 “当前 创建 bean 池 ”里 时 ， 将 抛 出 
BeanCurrentlyInCreationException 异 常 表示 循环 依赖 ， 而 对 于 创建 完毕 
的 bean 将 从 “当前 创建 bean 池 ”中 清除 掉 。 

我 们 通过 一 个 直观 的 测试 用 例 来 进行 分 析 。 

(1) 创建 配置 文件 。 


<bean id="testA" class="com.bean.TestA"> 





<constructor-arg index="0" ref="testB"/> 
</bean> 
<bean id="testB" class="com.bean.TestB"> 
«constructor-arg index="0" ref="testC"/> 


</bean> 


<bean id="testC" class="com.bean.TestC"> 
<constructor-arg index="0" ref="testA"/> 
</bean> 
(2) 创建 测试 用 例 。 
@Test(expected = BeanCurrentlyInCreationException.class) 
public void testCircleByConstructor() throws Throwable { 
try { 
new ClassPathXmlApplicationContext("test.xml"); 
} catch (Exception e) { 
/因为 要 在 创建 testC 时 抛 出 ; 
Throwable el = e.getCause().getCause().getCause(); 


throw e1; 


} 
针对 以 上 代码 的 分 析 如 下 。 
Spring 容 器 创建 “testA”bean， 上 自 先 去 “当前 创建 bean 池 ”查找 是 否 当 
前 bean 正 在 创建 ， 如 果 没 友 现 ， 则 继续 准备 其 需要 的 构造 器 参 
数 “testB”， 并 将 “testA” 标 识 符 放 到 “当前 创建 bean 池 ”。 
Spring 容 器 创建 “testB”bean， 肯 先 去 “当前 创建 bean 池 ”查找 是 否 当 
前 bean 正 在 创建 ， 如 果 没 友 现 ， 则 继续 准备 其 需要 的 构造 器 参 
数 “testC”， 并 将 “testB” 标 识 符 放 到 “当前 创建 bean 闻 ”。 
Spring 容 器 创建 “testC”bean， 肯 先 去 “当前 创建 bean 池 ”查找 是 否 当 
前 bean 正 在 创建 ， 如 果 没 友 现 ， 则 继续 准备 其 需要 的 构造 器 参 
数 “testA”， 并 将 “testC” 标 识 符 放 到 “当前 创建 Bean 池 ”。 
到 此 为 止 Spring 容 器 要 去 创建 “testA”bean， 发 现 该 bean 标 识 符 在 “ 当 
前 创建 bean 池 ”中 ， 因 为 表示 循环 依赖 ， 抛 出 


BeanCurrentlyInCreationException. 











2. setter 循 环 依赖 

表示 通过 setter 注 入 方式 构成 的 循环 依赖 。 对 于 setter 注 入 造成 的 依 
赖 是 通过 Spring 容器 提前 暴露 刚 完 成 构造 器 注入 但 未 完成 其 他 步骤 《如 
setter 注 入 ) 的 bean 来 完成 的 ， 而 且 只 能 解决 单 例 作用 域 的 bean 循 环 依 
赖 。 通 过 提前 骏 露 一 个 单 例 工 三 方法 ， 从 而 使 其 他 bean 能 引用 到 该 
bean， 如 下 代码 所 示 : 

addSingletonFactory(beanName, new ObjectFactory() { 





public Object getObject() throws BeansException { 
return getEarlyBeanReference(beanName, mbd, bean); 
} 
y 
有 具体 步骤 如 下 。 
(1) Spring 容器 创建 单 例 “testA”bean， 首 先 根据 无 参 构造 右 创 建 
bean， 并 骏 露 一 个 “ObjectFactory” 用 于 返回 一 个 提前 暴露 一 个 创建 中 的 
bean， 并 将 “testA” 标 识 符 放 到 “当前 创建 bean 池 ”， 然 后 进行 setter 注 
入 “testB”。 
(2) Spring 容器 创建 单 例 “testB”bean， 首 先 根 据 无 参 构造 器 创建 
bean， 并 骏 露 一 个 “ObjectFactory” 用 于 返回 一 个 提前 暴露 一 个 创建 中 的 
bean， 并 将 “testB” 标 识 符 放 到 “当前 创建 bean 池 ”， 然 后 进行 setter 注 
入 “circle”。 
(3) Spring 容 右 创建 单 例 “testC”bean， 首 先 根 据 无 参 构 造 器 创建 
bean， 并 骏 露 一 个 “ObjectFactory” 用 于 返回 一 个 提前 暴露 一 个 创建 中 的 
bean， 并 将 “testC” 标 识 符 放 到 “当前 创建 bean 池 ”， 然 后 进行 setter 注 
A “testA” o ETT TE A "testA" I] FH T PE BU 2&5 f "ObjectFactory" LJ , M 
而 使 用 它 返回 提前 暴露 一 个 创建 中 的 bean。 
(4) 最 后 在 依赖 注入 “testB” 和 “testA”， 完 成 setter 注 入 。 
3. prototype 汇 围 的 依赖 处 理 


对 于 “prototype” 作 用 域 bean，Spring 容 器 无 法 完成 依赖 注入 ， 因 为 
Spring 容器 不 进行 缓存 "prototype” 作 用 域 的 bean， 因 此 无 法 提前 暴露 一 
个 创建 中 的 bean。 示 例如 下 : 

(1) 创建 配置 文件 。 

<bean id="testA" class="com.bean.CircleA" scope="prototype"> 

<property name="testB" ref="testB"/> 

</bean> 

<bean id="testB" class="com.bean.CircleB" scope="prototype"> 

<property name-"testC" ref="testC"/> 

</bean> 

<bean id="testC" class="com.bean.CircleC" scope="prototype"> 

<property name="testA" ref="testA"/> 

</bean> 

(2) 创建 测试 用 例 。 
@Test(expected = BeanCurrentlyInCreationException.class) 
public void testCircleBySetterAndPrototype () throws Throwable { 
try { 
ClassPathXmlApplicationContext ctx = new 
ClassPathXmlApplicationContext( 
"testPrototype.xml"); 
System.out.println(ctx.getBean("testA")); 
} catch (Exception e) { 
Throwable el = e.getCause().getCause().getCause(); 


throw e1; 


} 
对 于 “singleton” 作 用 域 bean， 可 以 通 


过 “setAllowCircularReferences(false) ; ”来 禁用 循环 引用 。 

感谢 互联 网 时 代 ， 让 我 可 以 方便 地 获取 我 想 要 的 各 种 信息 ， 当 初 我 
刚 开 始 学 习 的 时 候 ， 一 直 纠 结 于 这 里 错综复杂 的 逻辑 ， 科 好 我 看 到 了 一 
篇 文章 解 开 了 我 心中 的 疑惑 。 在 此 ， 感 谢 原 作者 ， 并 将 原文 与 大 家 分 
享 ， 帮 助 大 家 更 好 的 理解 Spring 的 依赖 ， 大 家 可 以 从 http:/www .iflym. 
com/index.php/code/201208280001.html?K 3X3 JE X. 





5.7 创建 bean 


介绍 了 循环 依赖 以 及 Spring 中 的 循环 依赖 的 处 理 方式 后 ， 我 们 继续 
4.5 小 节 的 内 容 。 当 经 历 过 resolveBeforeInstantiation 方法 后 ， 程 序 有 两 
个 选择 ， 如 果 创 建 了 代理 或 者 说 重 写 了 
InstantiationAwareBeanPostProcessor 的 postProcessBeforeInstantiation 方 
法 并 在 方法 postProcess BeforeInstantiation 中 改变 了 bean， 则 直接 返回 就 
可 以 了 ， 奋 则 需要 进行 常规 bean 的 创建 。 而 这 常规 bean 的 创建 就是 在 
doCreateBean 中 完成 的 。 

protected Object doCreateBean(final String beanName, final 





RootBeanDefinition mbd, final 
Object[] args) { 

// Instantiate the bean. 

BeanWrapper instanceWrapper = null; 

if (mbd.isSingleton()) { 

instanceWrapper = 

this.factoryBeanInstanceCache.remove(beanName); 

} 

if (instanceWrapper == null) { 


/根据 指定 bean 使 用 对 应 的 策略 创建 新 的 实例 ， 如 : 工 三方 


法 、 构 造 函 数 自动 注入 、 简 单 初始 化 
instanceWrapper = createBeanInstance(beanName, mbd, args); 
} 
final Object bean = (instanceWrapper != null ? instanceWrapper. 
getWrappedInstance() : null); 
Class beanType = (instanceWrapper != null ? 
instanceWrapper.getWrappedClass() : null); 
// Allow post-processors to modify the merged bean definition. 
synchronized (mbd.postProcessingLock) 1 
if (!mbd.postProcessed) { 
I! NF] MergedBeanDefinitionPostProcessor 
applyMergedBeanDefinitionPostProcessors(mbd, beanType, 
beanName); 


mbd.postProcessed - true; 


j 
/* 
* 是 否 需要 提早 曝光 : 单 例 & 允 许 循环 依赖 & 当 前 bean 正 在 创建 
rp, dera PRA OR 
$7 
boolean earlySingletonExposure = (mbd.isSingleton() && 





this.allowCircularReferences && 
isSingletonCurrentlyInCreation(beanName)); 
if (earlySingletonExposure) { 
if (logger.isDebugEnabled()) { 
logger.debug("Eagerly caching bean ”+ beanName + 


"n 


to allow for resolving potential circular references"); 


} 


/为 避免 后 期 循环 依赖 ， 可 以 在 bean 初 始 化 完成 前 将 创建 实例 
的 ObjectFactory 加 入 工厂 
addSingletonFactory(beanName, new ObjectFactory() { 
public Object getObject() throws BeansException { 
/对 bean 再 一 次 依赖 引用 ， 主 要 应 用 


SmartInstantiationA ware BeanPost 


Processor, 


/其 中 我 们 熟知 的 AOP 就 是 在 这 里 将 advice 动 态 织 入 bean 
中 ， 若 没有 则 直接 返回 
bean， 不 做 任何 处 理 


return getEarlyBeanReference(beanName, mbd, bean); 


y 
j 
// Initialize the bean instance. 
Object exposedObject = bean; 
try 1 
始 依赖 bean 


/对 bean 进 行 填充 ， 将 各 个 属性 值 注 入 ， 其 中 ， 可 能 存在 依赖 
于 其 他 bean 的 属性 ， 则 会 递归 初 


populateBean(beanName, mbd, instanceWrapper); 
if (exposedObject != null) { 
1/ 调用 初始 化 方法 ， 比 如 init-method 


exposedObject = initializeBean(beanName, exposedObject, 
mbd); 


} 
catch (Throwable ex) { 
if (ex instanceof BeanCreationException && 
beanName.equals(((BeanCreationException) 
ex).getBeanName())) { 
throw (BeanCreationException) ex; 
} 
else { 
throw new 
BeanCreationException(mbd.getResourceDescription(), beanName, 


"Initialization of bean failed", ex); 


} 
if (earlySingletonExposure) { 
Object earlySingletonReference = getSingleton(beanName, false); 


/wearlySingletonReference 只 有 在 检测 到 有 循环 依赖 的 情况 下 才 


if (earlySingletonReference != null) { 


/如 果 exposedObject 没 有 在 初始 化 方法 中 被 改变 ， 也 就 是 没 


有 被 增强 
if (exposedObject == bean) { 
exposedObject = earlySingletonReference; 
(beanName)) { 
Jelse if (!this.allowRawInjectionDespiteWrapping && 
hasDependentBean 


String[] dependentBeans = getDependentBeans(beanName); 


Set<String> actualDependentBeans = new 


LinkedHashSet<String> 
(dependentBeans. length); 
for (String dependentBean : dependentBeans) { 
/检测 依赖 
if 
(IremoveSingletonIfCreatedForTypeCheckOnly(dependentBean)) { 
actualDependentBeans.add(dependentBean); 


} 

/* 
* | 因为 bean 创 建 后 其 所 依赖 的 bean 一 定 是 已 经 创建 的 ， 
* actualDependentBeans 不 为 空 则 表示 当前 bean 创 建 后 其 依 

赖 的 bean 却 没有 

没 全 部 创建 完 ， 也 就 是 说 存在 循环 依赖 
an 

if (lactualDependentBeans.isEmpty()) 1 
throw new BeanCurrentlyInCreationException(beanName, 


Tr 


"Bean with name "' + beanName + " has been injected 
into other beans [" + 

(actual DependentBeans) + 
StringUtils.collectionToCommaDelimitedString 

"] in its raw version as part of a circular reference, 

but has eventually been " + 

use the final version of the " + 

"wrapped. This means that said other beans do not 
"bean. This is often the result of over-eager type 


matching - consider using " + 


flag turned off, for example."); 


WT 


} 


getBeanNamesOfType' with the 'allowEagerlnit' 


j 
// Register bean as disposable. 
try 1 
/根据 scopse 注 册 bean 
registerDisposableBeanIfNecessary(beanName, bean, mbd); 
} 
catch (BeanDefinitionValidationException ex) { 
throw new BeanCreationException(mbd.getResourceDescription(), 
beanName, 
"Invalid destruction signature", ex); 
} 


return exposedObject; 


} 

尽管 日 志 与 异常 的 内 容 非 常 重要 ， 但 是 在 阅读 源码 的 时 候 似 乎 大 部 
分 人 都 会 直接 忽略 掉 。 在 此 不 深入 探讨 日 志 及 异常 的 设计 ， 我 们 看 看 整 
个 函数 的 概要 思路 。 

(1) 如 采 是 单 例 则 需要 首先 清除 缓存 。 

(2) 实例 化 bean， 将 BeanDefinition 转 换 为 BeanWrapper。 

转换 是 一 个 复杂 的 过 程 ， 但 是 我 们 可 以 尝试 概括 大 致 的 功能 ， 如 下 
所 示 。 

如 果 存 在 工厂 方法 则 使 用 工厂 方法 进行 初始 化 。 

一 个 类 有 多 个 构造 函数 ， 每 个 构造 函数 都 有 不 同 的 参数 ， 所 以 需 











根据 参数 锁定 构造 函数 并 进行 初始 化 。 

如 果 既 不 存在 工厂 方法 也 不 存在 市 有 参数 的 构造 函数 ， 则 使 用 默认 
的 构造 函数 进行 bean 的 实例 化 。 

(3) MergedBeanDefinitionPostProcessor 的 应 用 。 

bean 合 并 后 的 处 理 ，Autowired 注 解 正 是 通过 此 方法 实现 诸如 类 型 的 
预 解析 。 

(40 依赖 处 理 。 

在 Spring 中 会 有 循环 依赖 的 情况 ， 例 如 ， 当 A 中 含有 B 的 属性 ， 而 也 
中 又 含有 A 的 属性 时 就 会 构成 一 个 循环 依赖 ， 此 时 如 果 A 和 B 都 是 单 例 ， 
那么 在 Spring 中 的 处 理 方式 就 是 当 创 建 B 的 时 候 ， 涉 及 自动 注入 A 的 步 又 
时 ， 并 不 是 直接 去 再 次 创建 A， 而 是 通过 放 入 绥 存 中 的 ObjectFactory 来 
创建 实例 ， 这 样 就 解决 了 循环 依赖 的 问题 。 

(5) 属性 填充 。 将 所 有 属性 填充 至 bean 的 实例 中 。 

(6) 循环 依赖 检查 。 

之 前 有 提 到 过 ， 在 Sping 中 解决 循环 依赖 只 对 单 例 有 效 ， 而 对 于 
prototype 的 bean，Spring 没 有 好 的 解决 办 法 ， 唯 一 要 做 的 就 是 抛 出 异 
常 。 在 这 个 步骤 里 面 会 检测 已 经 加 载 的 bean 是 否 已 经 出 现 了 依赖 循 
环 ， 并 判断 是 人 否 需 要 抛 出 寞 第。 

(7) 注册 DisposableBean。 

如 果 配 置 了 destroy-method， 这 里 需要 注册 以 便于 在 销毁 时 候 调 
用 。 

(8) 完成 创建 并 返回 。 

可 以 看 到 上 面 的 步骤 非常 的 繁琐 ， 每 一 步骤 都 使 用 了 大 量 的 代码 来 
完成 其 功能 ， 最 复杂 也 是 最 难以 理解 的 当 属 循环 依赖 的 处 理 ， 在 真正 进 
入 doCreateBean 前 我 们 有 必要 先 了 解 下 循环 依赖 。 


5.7.1 &i| Æ bean] 3c f 











当 我 们 了 解 了 循环 依赖 以 后 就 可 以 深入 分 析 创 建 bean 的 每 个 步 又 
了 ， 首 先 我 们 从 createBeanInstance 开 始 。 
protected BeanWrapper createBeanInstance(String beanName, 
RootBeanDefinition mbd, Object[] args) { 
I/fi T class 
Class beanClass 7 resolveBeanClass(mbd, beanName); 
if (beanClass != null && 
!Modifier.isPublic(beanClass.getModifiers()) && !mbd. 
isNonPublicAccessAllowed()) 1 
throw new BeanCreationException(mbd.getResourceDescription(), 
beanName, 
"Bean class isn't public, and non-public access not allowed: " + 
beanClass.getName()); 
j 
// 如 果 工 三 方法 不 为 空 则 使 用 工厂 方法 初始 化 策略 
if (mbd.getFactoryMethodName() != null) { 
return instantiateUsingFactoryMethod(beanName, mbd, args); 
} 
// Shortcut when re-creating the same bean... 
boolean resolved = false; 
boolean autowireNecessary = false; 
if (args == null) { 
synchronized (mbd.constructorArgumentLock) { 
I-* BF BS FE AL, EAE RA AI [8183 2G 
所 以 调用 前 需要 先 根据 参数 锁定 
构造 函数 或 对 应 的 工厂 方法 
if (mbd.resolvedConstructorOrFactoryMethod != null) { 





resolved = true; 


autowireNecessary = mbd.constructorArgumentsResolved; 


} 
/如 果 已 经 解析 过 则 使 用 解析 好 的 构造 函数 方法 不 需要 再 次 锁定 
让 (resolved) { 
if (autowireNecessary) { 
RNE PRL EI EA 
return autowireConstructor(beanName, mbd, null, null); 
} 
else { 
/使 用 默认 构造 函数 构造 


return instantiateBean(beanName, mbd); 


} 
/需要 根据 参数 解析 构造 函数 
Constructor[] ctors = 
determineConstructorsFromBeanPostProcessors(beanClass, beanName); 
if (ctors != null || 
mbd.getResolvedAutowireMode() == RootBeanDefinition. 
AUTOWIRE_ 
CONSTRUCTOR || 
mbd.hasConstructorArgumentValues() || 
'ObjectUtils.isEmpty(args)) { 
JR E PL SITE A, 


return autowireConstructor(beanName, mbd, ctors, args); 


} 
/使 用 默认 构造 函数 构造 
return instantiateBean(beanName, mbd); 
} 
虽然 代码 中 实例 化 的 细节 非常 复杂 ， 但 是 在 createBeanIntance 方 法 
中 我 们 还 是 可 以 清晰 地 看 到 实例 化 的 逻辑 的 。 
(1) 如 果 在 RootBeanDefinition 中 存在 factoryMethodName 属 性 ， 或 
者 说 在 配置 文件 中 配置 了 factory-method， 那 么 Spring 会 尝试 使 用 
instantiateUsingFactoryMethod(beanName, mbd, args) 方 法 根据 
RootBeanDefinition 中 的 配置 生成 bean 的 实例 。 
(2) 解析 构造 函数 并 进行 构造 函数 的 实例 化 。 因 为 一 个 bean 对 应 
的 类 中 可 能 会 有 多 个 构造 函数 ， 而 每 个 构造 函数 的 参数 不 同 ，Spring 在 
根据 参数 及 类 型 去 判断 最 终 会 使 用 哪个 构造 函数 进行 实例 化 。 但 是 ， 判 
断 的 过 程 是 个 比较 消耗 性 能 的 步 台 ， 所 以 采用 绥 存 机 制 ， 如 果 已 经 解析 
过 则 不 需要 重复 解析 而 是 直接 从 RootBeanDefinition 中 的 属性 
resolvedConstructorOrFactoryMethod 绥 存 的 值 去 取 ， 否 则 需要 再 次 解 
析 ， 并 将 解析 的 结果 添加 至 RootBeanDefinition 中 的 属性 
resolvedConstructorOrFactoryMethod 中 。 








1. autowireConstructor 

对 于 实例 的 创建 Spring 中 分 成 了 两 种 情况 ， 一 种 是 通用 的 实例 化 ， 
男 一 种 是 市 有 参数 的 实例 化 。 带 有 参数 的 实例 化 过 程 相当 复杂 ， 因 为 存 
在 着 不 确定 性 ， 所 以 在 判断 对 应 参数 上 做 了 大 量 工作 。 


public BeanWrapper autowireConstructor( 





final String beanName, final RootBeanDefinition mbd, Constructor[] 
chosenCtors, final Object[] explicitArgs) { 
BeanWrapperImpl bw = new BeanWrapperImpl(); 
this.beanFactory.initBeanWrapper(bw); 


Constructor constructorToUse = null; 
ArgumentsHolder argsHolderToUse = null; 
Object[] argsToUse = null; 
/WexplicitArgs 通 过 getBean 方 法 传 入 
/如 果 getBean 方 法 调用 的 时 候 指 定 方 法 参数 那么 直接 使 用 
if (explicitArgs != null) { 
argsToUse = explicitArgs; 
}else { 
/如 采 在 getBean 方 法 时 候 没有 指定 则 答 试 从 配置 文件 中 解析 
Object[] argsToResolve = null; 
// 答 试 从 缓存 中 获取 
synchronized (mbd.constructorArgumentLock) { 
constructorToUse = (Constructor) 
mbd.resolvedConstructorOrFactoryMethod; 
if (constructorToUse != null && 


mbd.constructorArgumentsResolved) { 
// 从 缓存 中 取 
argsToUse = mbd.resolvedConstructorArguments; 
if (argsToUse == null) { 
/配置 的 构造 冰 数 参数 


argsToResolve = mbd.preparedConstructorArguments; 


} 
WU PRERAE PAPE. 
if (argsToResolve != null) { 
/解析 参数 类 型 ， 如 给 定 方法 的 构造 函数 A(inb,int) 则 通过 此 


方法 后 就 会 把 配置 中 的 

("1","1") 转 换 为 (1,1) 

/缓存 中 的 值 可 能 是 原始 值 也 肯 能 是 最 终 值 

args ToUse = resolvePreparedArguments(beanName, mbd, bw, 
constructor l'oUse, 


argsToResolve); 


j 
[FC BAF 
if (constructorToUse == null) { 
// Need to resolve the constructor. 
boolean autowiring = (chosenCtors != null || 
mbd.getResolvedAutowireMode() == 
RootBeanDefinition. AUTOWIRE _ 
CONSTRUCTOR); 
ConstructorArgumentValues resolvedValues = null; 
int minNrOfArgs; 
if (explicitArgs != null) { 
minNrOfArgs = explicitArgs.length; 
}else { 
/提取 配置 文件 中 的 配置 的 构造 函数 参数 
ConstructorArgumentValues cargs = 
mbd.getConstructorArgumentV alues(); 
/用 于 承载 解析 后 的 构造 函数 参数 的 值 
resolvedValues = new ConstructorArgumentValues(); 
/能 解析 到 的 参数 个 数 


minNrOfArgs = resolveConstructorArguments(beanName, mbd, 


bw, cargs, 


resolvedValues); 
} 
// Take specified constructors, if any. 
Constructor[] candidates = chosenCtors; 


if (candidates == null) { 


Class beanClass = mbd.getBeanClass(); 
try { 
candidates = (mbd.isNonPublicAccessAllowed() ? 
beanClass.getDeclaredConstructors():beanClass. 


getConstructors()); 
} 


catch (Throwable ex) { 
throw new 
BeanCreationException(mbd.getResourceDescription(), beanName， 


"Resolution of declared constructors on bean Class [" + 
beanClass.getName() + 


"] from ClassLoader [" + beanClass. getClassLoader() 
* "] failed", ex); 


j 
/排序 给 定 的 构造 函数 ，public 构 造 函 数 优先 参数 数量 降序 、 
public 构 造 函 数 参数 数量 降序 
AutowireUtils.sortConstructors(candidates); 
int minTypeDiffWeight = Integer. MAX_VALUE; 


Set<Constructor> ambiguousConstructors = null; 


List<Exception> causes = null; 


非 


for (int i = 0; i < candidates.length; i++) { 
Constructor<?> candidate = candidates[i]; 
Class[] paramTypes = candidate.getParameterTypes(); 
if (constructorToUse != null && argsToUse.length > 
paramTypes.length) { 
// 如 果 已 经 找到 选用 的 构造 函数 或 者 需要 的 参数 个 数 小 于 
当前 的 构造 函数 参数 个 数 则 
终止 ,因为 已 经 按照 参数 个 数 降序 排列 
break; 
} 
if (paramTypes.length < minNrOfArgs) { 
/参数 个 数 不 相 等 


Continue; 


ArgumentsHolder argsHolder; 

if (resolvedValues != null) { 
/有 参数 则 根据 值 构 造 对 应 参数 类 型 的 参数 
try { 


String[] paramNames = null; 





if (constructorPropertiesAnnotationAvailable) { 
/注释 上 获取 参数 名 称 
(candidate, paramTypes.length); 


paramNames = ConstructorPropertiesChecker. 
evaluateAnnotation 


} 
if (paramNames == null) { 


// 获 取 参 数 名 称 探索 器 


NameDiscoverer(); 
ParameterNameDiscoverer pnd = this.beanFactory. 
getParameter 
if (pnd != null) { 
// 获 取 指 定 构造 函数 的 参数 名 称 


paramNames = pnd.getParameterNames(candidate); 


} 
/根据 名 称 和 数据 类 型 创建 参数 持 有 者 
argsHolder = createArgumentArray( 
beanName, mbd, resolvedValues, bw, paramTypes, 
paramNames, 
candidate, autowiring); 
} 
catch (UnsatisfiedDependencyException ex) { 
if (this.beanFactory.logger.isTraceEnabled()) { 
this.beanFactory.logger.trace( 
"Ignoring constructor [" + candidate + "] of 
bean ' + beanName + ": " + ex); 
} 
if (i == candidates.length - 1 && constructorToUse == 
null) { 
if (causes != null) { 
for (Exception cause : causes) 1 


this.beanFactory.onSuppressedException(cause); 


throw ex; 
} 
else { 
// Swallow and try next constructor. 
if (causes == null) { 
causes = new LinkedList<Exception>(); 
l 
causes.add(ex); 


continue; 


} 
jelse { 
if (paramTypes.length != explicitArgs.length) { 
continue; 
} 
ITE] X PR BUA EL T D 
argsHolder = new ArgumentsHolder(explicitArgs); 
} 
/探测 是 否 有 不 确定 性 的 构造 函数 存在 ， 例 如 不 同 构造 函数 
的 参数 为 父子 关系 


int typeDiffWeight = (mbd.isLenientConstructorResolution() ? 








argsHolder.getTypeDifferenceWeight(paramTypes) : 
argsHolder. 
getAssignabilityWeight(paramTypes)); 
/如 果 它 代表 着 当前 最 接近 的 匹配 则 选择 作为 构造 函数 
if (typeDiffWeight < minTypeDiffWeight) { 


constructorToUse = candidate; 





argsHolderToUse = argsHolder; 
argsToUse = argsHolder.arguments; 
minTypeDiffWeight = typeDiffWeight; 
ambiguousConstructors = null; 
}else if (constructorToUse != null && typeDiffWeight == 
minTypeDiffWeight) { 
if (ambiguousConstructors == null) { 
ambiguousConstructors = new 
LinkedHashSet<Constructor>(); 
ambiguousConstructors.add(constructorToUse); 
} 


ambiguousConstructors.add(candidate); 


} 
if (constructorToUse == null) { 
throw new 
BeanCreationException(mbd.getResourceDescription(), beanName, 
"Could not resolve matching constructor " + 
"(hint: specify index/type/name arguments for simple 
parameters to avoid type ambiguities)"); 
}else if (ambiguousConstructors != null && 
!mbd.isLenientConstructor 
Resolution()) { 
throw new 
BeanCreationException(mbd.getResourceDescription(), beanName, 
"Ambiguous constructor matches found in bean " + beanName 


+ TTT ov + 


"(hint: specify index/type/name arguments for simple 
parameters to avoid type ambiguities): " + 
ambiguousConstructors); 

} 

if (explicitArgs == null) { 
/将 解析 的 构造 函数 加 入 缓存 


argsHolderToUse.storeCache(mbd, constructorToUse); 


} 
try { 
Object beanInstance; 
if (System.getSecurityManager() != null) { 
final Constructor ctorToUse = constructorToUse; 
final Object[] argumentsToUse = argsToUse; 
beanInstance = AccessController.doPrivileged(new 
PrivilegedAction< 
Object^() { 
public Object run() { 
return beanFactory.getInstantiationStrategy().instantiate( 
mbd, beanName, beanFactory, ctor ToUse, 
arguments ToUse); 
j 
}, beanFactory.getA ccessControlContext()); 
j 
else { 
beanInstance = 


this.beanFactory.getInstantiationStrategy().instantiate( 


mbd, beanName, this.beanFactory, constructorToUse, 
argsToUse); 
} 
/将 构建 的 实例 加 入 BeanWrapper 中 
bw.setWrappedInstance(beanInstance); 
return bw; 
} 
catch (Throwable ex) { 
throw new BeanCreationException(mbd.getResourceDescription(), 
beanName, 


"Instantiation of bean failed", ex); 


} 

逻辑 很 复杂 ， 函 数 代码 量 很 大 ， 不 知道 你 是 否 坚 持 读 完了 整个 函数 
并 理解 了 整个 功能 呢 ? 这 里 要 先 吐 个 槽 ， 笔 者 觉得 这 个 函数 的 写法 完全 
不 符合 Spring 的 一 贯 风 格 ， 如 果 你 一 直 跟 随笔 者 的 分 析 思 路 到 这 里 ， 相 
信 你 或 多 或 少 对 Spring 的 编码 风格 有 所 了 解 ，Spring 的 一 贯 做 法 是 将 复 
如 的 逻辑 分 解 ， 分 成 N 个 小 函数 的 舱 套 ， 每 一 层 都 是 对 下 一 层 逻 辑 的 总 
结 及 概要 ， 这 样 使 得 每 一 层 的 逻辑 会 变 得 简单 容易 理解 。 在 上 面 的 函数 
中 ， 包 含 着 很 多 的 逻辑 实现 ， 笔 者 觉得 至 少 应 该 将 逻辑 封 状 在 不 同 函 数 
中 而 使 得 在 autowireConstructor 中 的 逻辑 清晰 明了 。 

我 们 总 览 一 下 整个 函数 ， 其 实现 的 功能 考虑 了 以 下 几 个 方面 。 

(1) 构造 函数 参数 的 确定 。 

根据 explicitArgs 参 数 判 断 。 

如 果 传 入 的 参数 explicitArgs 不 为 空 ， 那 边 可 以 直接 确定 参数 ， 因 为 
explicitArgs 参 数 是 在 调用 Bean 的 时 候 用 户 指定 的 ， 在 BeanFactory 类 中 存 
在 这 样 的 方法 : 

















Object getBean(String name, Object... args) throws BeansException; 

在 获取 bean 的 时 候 ， 用 户 不 但 可 以 指定 bean 的 名 称 还 可 以 指定 bean 
所 对 应 类 的 构造 函数 或 者 工厂 方法 的 方法 参数 ， 主 要 用 于 静态 工厂 方法 
的 调用 ， 而 这 里 是 需要 给 定 完全 匹配 的 参数 的 ， 所 以 ， 便 可 以 判断 ， 如 
果 传 入 参数 explicitArgs 不 为 空 ， 则 可 以 确定 构造 函数 参数 就 是 它 。 

缓存 中 获取 。 

除 此 之 外 ， 确 定 参 数 的 办 法 如 果 之 前 已 经 分 析 过 ， 也 束 是 说 构造 函 
数 参数 已 经 记录 在 缓存 中 ， 那 么 便 可 以 直接 拿 来 使 有 用。 而且， 这 里 要 提 
到 的 是 ， 在 缓存 中 绥 存 的 可 能 是 参数 的 最 终 类 型 也 可 能 是 参数 的 初始 类 
型 ， 例 如 : 构造 函数 参数 要 求 的 是 int 类 型 ， 但 是 原始 的 参数 值 可 能 是 
String 类 型 的 *1”， 那 么 即使 在 缓存 中 得 到 了 人 参数， 也 需要 经 过 类 型 转换 
器 的 过 滤 以 确保 参数 类 型 与 对 应 的 构造 函数 参数 类 型 完全 对 应 。 

配置 文件 获取 。 

如 果 不 能 根据 传 入 的 参数 explicitArgs 确 定 构 造 函 数 的 参数 也 无 法 在 
绥 存 中 得 到 相关 信息 ， 那 么 只 能 开始 新 一 轮 的 分 析 了 。 

分 析 从 获取 配置 文件 中 配置 的 构造 函数 信息 开始 ， 经 过 之 前 的 分 
析 ， 我 们 知道 ，Spring 中 配置 文件 中 的 信息 经 过 转换 都 会 通过 
BeanDefinition 实 例 承载 ， 也 就 是 参数 mbd 中 包含 ， 那 么 可 以 通过 调用 
mbd.getConstructorArgumentValues0) 来 获取 配置 的 构造 函数 信息 。 有 了 
配置 中 的 信息 便 可 以 获取 对 应 的 参数 值 信息 了 ， 获 取 参 数值 的 信息 包括 
直接 指定 值 ， 如 : 直接 指定 构造 函数 中 某 个 值 为 原始 类 型 String KW, 
或 者 是 一 个 对 其 他 bean 的 引用 ， 而 这 一 处 理 委 托 给 
resolveConstructorArguments 方 法 ， 并 返回 能 解析 到 的 参数 的 个 数 。 

(2) 构造 函数 的 确定 。 

经 过 了 第 一 步 后 已 经 确定 了 构造 函数 的 参数 ， 接 下 来 的 任务 承 是 根 
据 构 造 函 数 参数 在 所 有 构造 函数 中 锁定 对 应 的 构造 函数 ， 而 匹配 的 方法 
就 是 根据 参数 个 数 匹 配 ， 所 以 在 匹配 之 前 需要 先 对 构造 函数 按照 public 


























构造 函数 优先 参数 数量 降序 、 非 public 构 造 函 数 参 数 数量 降序 。 这 样 可 
以 在 过 历 的 情况 下 迅速 判断 排 在 后 面 的 构造 函数 参数 个 数 是 否 符 合 条 
TE. 

由 于 在 配置 文件 中 并 不 是 唯一 限制 使 用 参数 位 置 索引 的 方式 去 创 
建 ， 同 样 还 文 振 指定 参数 名 称 进 行 设 定 参数 值 的 情况 ， 如 <constructor- 
arg name="aa">， 那 么 这 种 情况 就 需要 首先 确定 构造 函数 中 的 参数 名 
称 。 

获取 参数 名 称 可 以 有 两 种 方式 ， 一 种 是 通过 注解 的 方式 直接 获取 ， 
另 一 种 就 是 使 用 Spring 中 提供 的 工具 类 ParameterNameDiscoverer 来 获 
取 。 构 造 函 数 、 参 数 名 称 、 参 数 类 型 、 参 数值 都 确定 后 就 可 以 锁定 构造 
函数 以 及 转换 对 应 的 参数 类 型 了 。 

(3) 根据 确定 的 构造 函数 转换 对 应 的 参数 类 型 。 

主要 是 使 用 Spring 中 提供 的 类 型 转换 器 或 者 用 户 提 供 的 自 定义 类 型 
转换 器 进行 转换 。 

(4) 构造 函数 不 确定 性 的 验证 。 

当然 ， 有 时 候 即 使 构造 函数 、 参 数 名 称 、 参 数 类 型 、 参 数值 都 确定 
后 也 不 一 定 会 直接 锁定 构造 函数 ， 不 同 构造 函数 的 参数 为 父子 关系 ， 所 
以 Spring 在 最 后 又 做 了 一 次 验证 。 

(5) 根据 实例 化 策略 以 及 得 到 的 构造 函数 及 构造 函数 参数 实例 化 
Bean。 后 面 章 节 中 将 进行 讲解 。 

2. instantiateBean 

经 历 了 带 有 参数 的 构造 函数 的 实例 构造 ， 相 信 你 会 非常 轻松 愉快 地 
理解 不 市 参数 的 构造 函数 的 实例 化 过 程 。 


protected BeanWrapper instantiateBean(final String beanName, final 























RootBean 
Definition mbd) { 
try { 


Object beanInstance; 
final BeanFactory parent = this; 
if (System.getSecurityManager() != null) { 
beanInstance = AccessController.doPrivileged(new 
PrivilegedAction 
<Object>() 1 
public Object run() { 


return getInstantiationStrategy().instantiate(mbd, 


beanName, 
parent); 
j 
}, getAccessControlContext()); 
j 
else { 
beanInstance - getInstantiationStrategy().instantiate(mbd, 
beanName, 
parent); 
j 
BeanWrapper bw = new BeanWrapperImpl(beanInstance); 
initBeanWrapper(bw); 
return bw; 


} 
catch (Throwable ex) { 
throw new BeanCreationException(mbd.getResourceDescription(), 
beanName, 


"Instantiation of bean failed", ex); 


} 

你 会 发现 ， 此 方法 并 没有 什么 实质 性 的 逻辑 ， 带 有 参数 的 实例 构造 
中 ，Spring 把 精力 都 放 在 了 构造 函数 以 及 参数 的 匹配 上 ， 所 以 如 末 没 有 
参数 的 话 那 将 是 非常 简单 的 一 件 事 ， 直 接 调 用 实例 化 集 略 进 行 实例 化 就 
可 以 了 。 

3. 实例 化 策略 

实例 化 过 程 中 反复 提 到 过 实例 化 策略 ， 那 这 又 是 做 什么 用 的 呢 ? 其 
实 ， 经 过 前 面 的 分 析 ， 我 们 已 经 得 到 了 足以 实例 化 的 所 有 相关 信息 ， 完 
全 可 以 使 用 最 简单 的 反射 方法 直接 反射 来 构造 实例 对 象 ， 但 是 Spring 却 
并 没有 这 么 做 。 


SimpleInstantiationStrategy.java 








public Object instantiate(RootBeanDefinition beanDefinition, String 
beanName, BeanFactory 
owner) 1 
IURE i ELT i EC NAS FF PR TIE RU] A m fH]. cglib 进行 
动态 代理 ， 因 为 可 以 在 创建 代理 的 同 
时 将 动态 方法 织 入 类 中 ， 
/但 是 如 果 没 有 需要 动态 改变 得 方法 ， 为 了 方便 直接 反射 就 可 以 











if (beanDefinition.getMethodOverrides().isEmpty()) 1 
Constructor<?> constructor ToUse; 
synchronized (beanDefinition.constructorArgumentLock) { 
constructorToUse = (Constructor<? 
>)beanDefinition.resolvedConstructor 
OrFactoryMethod; 
if (constructorToUse == null) { 


final Class clazz = beanDefinition.getBeanClass(); 


if (clazz.isInterface()) { 
throw new BeanInstantiationException(clazz, "Specified 
class 
is an interface"); 
} 
try { 
if (System.getSecurityManager() != null) { 
constructorToUse = AccessController.doPrivileged(new 
PrivilegedExceptionAction<Constructor>() { 
public Constructor run() throws Exception { 


return clazz.getDeclaredConstructor((Class[]) null); 


y 
j 
else { 
null); 
constructor ToUse = 
clazz.getDeclaredConstructor((Class[]) 
} 
constructor ToUse; 
beanDefinition.resolvedConstructorOrFactoryMethod = 
j 
catch (Exception ex) 1 
constructor found", ex); 


throw new BeanInstantiationException(clazz, "No default 


} 
return BeanUtils.instantiateClass(constructorToUse); 
}else { 
// Must generate CGLIB subclass. 
return instantiateWithMethodInjection(beanDefinition, beanName, 
owner); 
j 

j 

CglibSubclassingInstantiationStrategy.java 

public Object instantiate(Constructor ctor, Object[] args) { 

Enhancer enhancer = new Enhancer(); 
enhancer.setSuperclass(this.beanDefinition.getBeanClass()); 
enhancer.setCallbackFilter(new CallbackFilterImpl()); 
enhancer.setCallbacks(new Callback[] 1 
NoOp.INSTANCE, 
new LookupOverrideMethodInterceptor(), 
new ReplaceOverrideMethodInterceptor() 
y 
return (ctor == null) ? 
enhancer.create() : 
enhancer.create(ctor.getParameterTypes(), args); 
} 

看 了 上 面 两 个 函数 后 似乎 我 们 已 经 感受 到 了 Spring 的 良 苦 用 心 以 及 
为 了 能 更 方便 地 使 用 Spring 而 做 了 大 量 的 工作 。 程 序 中 ， 首 先 判断 如 果 
beanDefinition.getMethodOverrides() 7j F t5 3); zi H] A fs H]replacegX zr 
lookup 的 配置 方法 ， 那 么 直接 使 用 反射 的 方式 ， 简 单 快 捷 ， 但 是 如 果 使 
用 了 这 两 个 特性 ， 在 直接 使 用 反射 的 方式 创建 实例 就 不 慨 了 了 ， 因 为 需要 











将 这 两 个 配置 提供 的 功能 切入 进去 ， 所 以 就 必须 要 使 用 动态 代理 的 方式 
将 包含 两 个 特性 所 对 应 的 逻辑 的 拦截 增强 器 设置 进去 ， 这 样 才 可 以 保证 
在 调用 方法 的 时 候 会 被 相 应 的 拦截 嚣 增强， 返回 值 为 包含 拦截 器 的 代理 
实例 。 

对 于 拦截 器 的 处 理 方法 非常 简单 ， 不 再 详细 介绍 ， 如 果 读 者 有 兴 
趣 ， 可 以 仔细 研读 第 7 章 中 关于 AOP 的 介绍 ， 对 动态 代理 方面 的 知识 会 
有 更 详细 地 介绍 。 

5.7.2 记录 创建 bean 的 ObjectFactor 


在 doCreate 函 数 中 有 这 样 一 段 代 人 码 : 
boolean earlySingletonExposure = (mbd.isSingleton() && 
this.allowCircularReferences && 
isSingletonCurrentlyInCreation(beanName)); 
if (earlySingletonExposure) { 
if (logger.isDebugEnabled()) 1 
logger.debug("Eagerly caching bean ' + beanName + 


LLAI 


to allow for resolving potential circular references"); 


} 
/为 避免 后 期 循环 依赖 ， 可 以 在 bean 初 始 化 完成 前 将 创建 实例 
的 ObjectFactory 加 入 工厂 


addSingletonFactory(beanName, new ObjectFactory() { 
public Object getObject() throws BeansException 1 
Processor, 
/对 bean 再 一 次 依赖 引用 ， 主 要 应 用 
SmartinstantiationAware BeanPost 
bean， 不 做 任何 处 理 
/其 中 我 们 熟知 的 AOP 就 是 在 这 里 将 advice 动 态 织 入 bean 


H, ERAN AIR E 
return getEarlyBeanReference(beanName, mbd, bean); 
} 
y 
j 

这 段 代 码 不 是 很 复杂 ， 但 是 很 多 人 不 是 太 理 解 这 段 代 码 的 作用 ， 而 
且 ， 这 段 代 码 仅 从 此 函数 中 去 理解 也 很 难 卉 懂 其 中 的 含义 ， 我 们 需要 从 
全 局 的 角度 去 思考 Spring 的 依赖 解决 办 法 。 

earlySingletonExposure: 从 字面 的 意思 理解 就 是 提早 曝光 的 单 例 ， 
我 们 暂 不 定义 它 的 学 名 叫 什么 ， 我 们 感 兴 趣 的 是 有 哪些 条 件 影响 这 个 
EE 

mbd.isSingleton(): 没有 太 多 可 以 解释 的 ， 此 RootBeanDefinition 代 
表 的 是 否 是 单 例 。 

this.allowCircularReferences: 是 否 允 许 循环 依赖 ， 很 抱歉 ， 并 没有 
找到 在 配置 文件 中 如 何 配置 ， 但 是 在 
AbstractRefreshableApplicationContext 中 提供 了 设置 函数 ， 可 以 通过 人 硬 
编码 的 方式 进行 设置 或 者 可 以 通过 上 自 定义 命名 空间 进行 配置 ， 其 中 硬 编 
码 的 方式 代码 如 下 。 

ClassPathXmlApplicationContext bf = new 





ClassPathXmlApplicationContext ("aspectTest.xml"); 
bf.setAllowBeanDefinitionOverriding(false); 
isSingletonCurrentlyInCreation(beanName): 该 bean 是 人 否 在 创建 中 。 
在 Spring 中 ， 会 有 个 专门 的 属性 默认 为 DefaultSingletonBeanRegistry 的 
singletonsCurrentlyInCreation 来 记录 bean 的 加 载 状态 ， 在 bean 开 始 创 建 前 
会 将 beanName 记 录 在 属性 中 ， 在 bean 创 建 结束 后 会 将 beanName 从 属性 
中 移 除 。 那 么 我 们 跟随 代码 一 路 走 来 可 是 对 这 个 属性 的 记录 并 没有 多 少 
印象 ， 这 个 状态 是 在 哪里 记录 的 呢 ? 不 同 scope 的 记录 位 置 并 不 一 样 ， 





我 们 以 singleton 为 例 ， 在 singleton 下 记录 属性 的 函数 是 在 
DefaultSingletonBeanRegistry 类 的 public Object getSingleton(String 
beanName, ObjectFactory singletonFactory) 函 数 的 
beforeSingletonCreation(beanName) 和 afterSingletonCreation(beanName) 
中 ， 在 这 两 段 函数 中 分 别 
this.singletonsCurrentlyInCreation.add(beanName) 与 
this.singletonsCurrentlyIn Creation.remove(beanName) 来 进行 状态 的 记录 
与 移 除 。 

经 过 以 上 分 析 我 们 了 解 变量 earlySingletonExposure 是 否 是 单 例 、 
信人 允许 循环 依赖 、 是 售 对 应 的 bean 正 在 创建 的 条 件 的 综合 uiis 
件 都 满足 时 会 执行 addSingletonFactory 操 作 ， 那 么 加 入 SingletonFactory 
的 作用 是 什么 呢 ? 又 是 在 什么 时 候 调 用 呢 ? 

我 们 还 是 以 最 简单 AB 循 环 依赖 为 例 ， 类 A 中 含有 属性 类 B， 而 类 B 
中 叉 会 含有 属性 类 A， 那 么 初始 化 beanA 的 过 程 如 图 5-3 所 示 。 








开始 创建 bean( 记 录 beanNameA) 


addSingletonFactory 


populateB ean( 填 充 属性 ) 








开始 创建 beam( 记 录 beanNameB) | 
¥ 
—— Er 


populateB ean( 填 充 属性 ) 














结束 创建 bean( 移 除 beanNameB) 








图 5-3 处 理 循 环 依赖 
图 5-3 中 展示 了 创建 beanA 的 流程 ， 图 中 我 们 看 到 ， 在 创建 A 的 时 候 


首先 会 记录 类 A 所 对 应 的 beanName， 并 将 beanA 的 创建 工厂 加 入 缓存 

中 ， 而 在 对 A 的 属性 填充 也 就 是 调用 populate 方 法 的 时 候 又 会 再 一 次 的 对 
B 进 行 递归 创建 。 同 样 的 ， 因 为 在 B 中 同样 存在 A 属 性 ， 因 此 在 实例 化 B 
的 的 populate 方 法 中 又 会 再 次 地 初始 化 B， 也 就 是 图 形 的 最 后 ， 调 用 
getBean(A)。 关 键 是 在 这 里 ， 有 心 的 同学 可 以 去 找 找 这 个 代码 的 实现 方 
式 ， 我 们 之 前 已 经 讲 过 ， 在 这 个 函数 中 并 不 是 直接 去 实例 化 A， 而 是 先 
去 检测 缓存 中 是 否 有 已 经 创建 好 的 对 应 的 bean， 或 者 是 否 已 经 创建 好 的 
ObjectFactory， 而 此 时 对 于 A 的 ObjectFactory 我 们 早已 经 创建 ， 所 以 便 不 
会 再 去 向 后 执行 ， 而 是 直接 调用 ObjectFactory 去 创建 A。 这 里 最 关键 的 
是 ObjectFactory 的 实现 。 











addSingletonFactory(beanName, new ObjectFactory() { 
public Object getObject() throws BeansException { 
/对 bean 再 一 次 依赖 引用 ， 主 要 应 用 SmartInstantiationA ware 
BeanPost 
Processor, 
bean， 不 做 任何 处 理 
/其 中 我 们 熟知 的 AOP 就 是 在 这 里 将 advice 动 态 织 入 bean 中 ， 若 
没有 则 直接 返回 
return getEarlyBeanReference(beanName, mbd, bean); 
} 
y 
其 中 getEarlyBeanReference 的 代码 如 下 : 
protected Object getEarlyBeanReference(String beanName, 
RootBeanDefinition mbd, Object 
bean) { 
Object exposedObject = bean; 
if (bean != null && !mbd.isSynthetic() && 


hasInstantiationAwareBean PostProcessors()) 1 
for (BeanPostProcessor bp : getBeanPostProcessors()) { 
if (bp instanceof SmartInstantiationAwareBeanPostProcessor) { 
SmartInstantiationA wareBeanPostProcessor ibp = 
(SmartInstantiation 
AwareBeanPostProcessor) bp; 


exposedObject = ibp.getEarlyBeanReference(exposedObject, 


beanName); 
if (exposedObject == null) { 
return exposedObject; 
} 
} 
} 
} 
return exposedObject; 
} 


在 getEarlyBeanReference 函 数 中 并 没有 太 多 的 逻辑 处 理 ， 或 者 说 除 
了 后 处 理 器 的 调用 外 没有 别 的 处 理工 作 ， 根 据 以 上 分 析 ， 基 本 可 以 理 清 
Spring 处 理 循 环 依赖 的 解决 办 法 ， 在 B 中 创建 依赖 A 时 通过 
ObjectFactory 提 供 的 实例 化 方法 来 中 断 A 中 的 属性 填充 ， 使 B 中 持 有 的 A 
仅仅 是 刚 唱 初始 化 并 没有 填充 任何 属性 的 A， 而 这 正 初 始 化 A 的 步骤 还 
是 在 最 开始 创建 A 的 时 候 进 行 的 ， 但 是 因为 A 与 B 中 的 A 所 表示 的 属性 地 
址 是 一 样 的， 所 以 在 A 中 创建 好 的 属性 填充 自然 可 以 通过 B 中 的 A 获取 ， 
这 样 就 解决 了 循环 依赖 的 问题 。 

5.7.3 属性 注入 

在 了 解 循 环 依 赖 的 时 候 ， 我 们 曾经 反复 提 到 了 populateBean 这 个 函 





数 ， 也 多 少 了 解 了 这 个 函数 的 主要 功能 就 是 属性 填充 ， 那 么 究竟 是 如 何 
实现 填充 的 呢 ? 
protected void populateBean(String beanName, AbstractBeanDefinition 

mbd, BeanWrapper bw) { 

Property Values pvs = mbd.getProperty Values(); 

if (bw == null) { 

if (!pvs.isEmpty()) 1 
throw new BeanCreationException( 


mbd.getResourceDescription(), beanName, "Cannot apply 





property 
values to null instance"); 
} 
else { 
/没有 可 填充 的 属性 
return; 
} 
} 
/给 InstantiationAwareBeanPostProcessors 最 后 一 次 机 会 在 属性 设 
置 前 来 改变 bean 


/如 : 可 以 用 来 支持 属性 注入 的 类 型 
boolean continueWithPropertyPopulation = true; 
if (!Imbd.isSynthetic() && 
hasInstantiationA wareBeanPostProcessors()) 1 
for (BeanPostProcessor bp : getBeanPostProcessors()) 1 
if (bp instanceof InstantiationAwareBeanPostProcessor) 1 
PostProcessor) bp; 


InstantiationA wareBeanPostProcessor ibp = (Instantiation 


AwareBean 


(‘ibp.postProcessA fterInstantiation(bw.getWrappedInstance(), 
beanName)) { 
continueWithPropertyPopulation = false; 


break; 


} 
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if (!IcontinueWithPropertyPopulation) { 





return; 
j 
if (mbd.getResolvedAutowireMode() == 
RootBeanDefinition.AUTOWIRE BY NAME || 
mbd.getResolvedAutowireMode() == 
RootBeanDefinition. AUTOWIRE_BY_TYPE) { 
MutableProperty Values newPvs = new MutableProperty Values(pvs); 
// Add property values based on autowire by name if applicable. 
/根据 名 称 目 动 注入 
if (mbd.getResolvedAutowireMode() == 
RootBeanDefinition. AUTOWIRE_BY_NAME) { 
autowireByName(beanName, mbd, bw, newPvs); 


} 
// Add property values based on autowire by type if applicable. 





/根据 类 型 自动 注入 
if (mbd.getResolvedAutowireMode() == 
RootBeanDefinition.AUTOWIRE BY TYPE) { 
autowireByType(beanName, mbd, bw, newPvs); 
j 
pvs - newPvs; 
j 
/后 处 理 器 已 经 初始 化 
boolean hasInstAwareBpps = 
hasInstantiationA wareBeanPostProcessors(); 
/需要 依赖 检查 
boolean needsDepCheck = (mbd.getDependencyCheck() != 
RootBeanDefinition. 
DEPENDENCY_CHECK_NONE); 
if (hasInstAwareBpps || needsDepCheck) { 
PropertyDescriptor[] filteredPds = filterPropertyDescriptors 
ForDependency 
Check(bw); 
if (hasInstAwareBpps) 1 
for (BeanPostProcessor bp : getBeanPostProcessors()) { 
if (bp instanceof InstantiationA wareBeanPostProcessor) 1 
InstantiationA wareBeanPostProcessor ibp = 
(InstantiationA wareBean 
PostProcessor) bp; 
/对 所 有 需要 依赖 检查 的 属性 进行 后 处 理 
pvs = ibp.postProcessProperty Values(pvs, filteredPds, 
bw.getWrappedInstance(), beanName); 


让 (pvs == null) { 


return; 


if (needsDepCheck) { 
/依赖 检查 ， 对 应 depends-on 属 性 ，3.0 已 经 弃 用 此 属性 
checkDependencies(beanName, mbd, filteredPds, pvs); 


} 
/将 属性 应 用 到 bean 中 
applyPropertyValues(beanName, mbd, bw, pvs); 
} 
f£populateBean rk Zi rH Het FIERA TE o 

(1) InstantiationA wareBeanPostProcessor A f 45 [f] 
postProcessAfterInstantiation 函 数 的 应 用 ， 此 函数 可 以 控制 程序 是 否 继 续 
进行 属性 填充 。 

(2) 根据 注入 类 型 (byName/byType) ， 提 取 依 赖 的 bean， 并 统一 
存 入 PropertyValues 中 。 

(3) 应 用 InstantiationAwareBeanPostProcessor 处 理 器 的 
postProcessPropertyValues 方 法 ， 对 属性 获取 完毕 填充 前 对 属性 的 再 次 处 
理 ， 典 型 应 用 是 RequiredAnnotationBeanPostProcessor 类 中 对 属性 的 验 
证 。 





(4) 将 所 有 PropertyValues 中 的 属性 填充 全 BeanWrapper 中 。 
在 上 面 的 步骤 中 有 几 个 地 方 是 我 们 比较 感 兴趣 的 ， 它 们 分 别 是 依赖 
YEA. ( autowire ByName/autowireByType) 以 及 属性 填充 ， 那 么 ， 接 下 


来 进一步 分 析 这 几 个 功能 的 实现 细 市 。 
1. autowireByName 
上 文 提 到 根据 注入 类 型 (byName/byType) ， 提 取 依 赖 的 bean， 并 
统一 存 入 PropertyValues 中 ， 那 么 我 们 首先 了 解 下 byName 功 能 是 如 何 实 
现 的 。 
protected void autowireByName( 
String beanName, AbstractBeanDefinition mbd, BeanWrapper bw, 
MutableProperty 
Values pvs) { 
/寻找 bw 中 需要 依赖 注入 的 属性 
String[] propertyNames = unsatisfiedNonSimpleProperties(mbd, 
bw); 
for (String propertyName : propertyNames) { 
if (containsBean(propertyName)) { 
/递归 初始 化 相关 的 bean 
Object bean = getBean(propertyName); 
pvs.add(propertyName, bean); 
/注册 依赖 
registerDependentBean(propertyName, beanName); 
if (logger.isDebugEnabled()) { 
logger.debug(" Added autowiring by name from bean name " 


Y 


+ beanName + 


WY 


"' via property " + propertyName + "' to bean named "" 


+ propertyName + """); 


else { 


if (logger.isTraceEnabled()) { 


logger.trace("Not autowiring property 


WY 


+ propertyName + ” 
of 
bean ' + beanName + 


"by name: no matching bean found"); 


} 
如 果 读 者 之 前 了 解 了 autowire 的 使 用 方法 ， 相 信 理 解 这 个 函数 的 功 
能 不 会 太 困难 ， 无 非 是 在 传 入 的 参数 pvs 中 找 出 已 经 加 载 的 bean， 并 弟 
归 实 例 化 ， 进 而 加 入 到 pvs 中 。 
2. autowireByType 
autowireByType 与 autowireByName 对 于 我 们 理解 与 使 用 来 说 复杂 
程度 都 很 相似 ， 但 是 其 实现 功能 的 复杂 上 度 却 完全 不 一 样 。 
protected void autowireByType( 
String beanName, AbstractBeanDefinition mbd, BeanWrapper bw, 
MutableProperty Values pvs) { 
TypeConverter converter = getCustomT ypeConverter(); 
if (converter == null) { 
converter = bw; 
} 
Set<String> autowiredBeanNames = new LinkedHashSet<String> 
(4); 
/寻找 bw 中 需要 依赖 注入 的 属性 
String[] propertyNames = unsatisfiedNonSimpleProperties(mbd, 
bw); 


for (String propertyName : propertyNames) { 
try { 
PropertyDescriptor pd = 
bw.getPropertyDescriptor(property Name); 
// Don't try autowiring by type for type Object: never makes 


sense, 
// even if it technically is a unsatisfied, non-simple property. 
if (VObject.class.equals(pd.getProperty Type())) { 
/探测 指定 属性 的 set 方 法 
MethodParameter methodParam = BeanUtils.getWriteMethod 
Parameter(pd); 
boolean eager = !PriorityOrdered.class. isAssignableFrom 
(bw.get 


WrappedClass()); 

DependencyDescriptor desc = new 
AutowireByTypeDependencyDescriptor 

(methodParam, eager); 

/解析 指定 beanName 的 属性 所 匹配 的 值 ， 并 把 解析 到 的 
属性 名 称 存储 在 

autowiredBeanNames 中 ， 当 属性 存在 多 个 封装 bean 时 如 

//@Autowired private List<A> aList; 将 会 找到 所 有 匹配 A 类 





型 的 bean 并 

将 其 注入 

Object autowiredArgument = resolveDependency(desc, 
beanName, 


autowiredBeanNames, converter); 


if (autowiredArgument != null) { 


pvs.add(propertyName, autowiredArgument); 

} 

for (String autowiredBeanName : autowiredBeanNames) { 
/注册 依赖 
registerDependentBean(autowiredBeanName, beanName); 
if (logger.isDebugEnabled()) { 


Tr 


beanName + "" via property " + 
logger.debug("Autowiring by type from bean name ™ + 
propertyName + "to bean named "+ 


autowiredBeanName + """); 


} 


autowiredBeanNames.clear(); 


} 
catch (BeansException ex) { 
throw new 
Unsatisfied DependencyException(mbd.getResourceDescription(), 


beanName, propertyName, ex); 


} 

实现 根据 名 称 目 动 下 配 的 第 一 步 束 是 寻找 bw 中 需要 依赖 注入 的 属 
性 ， 同 样 对 于 根据 类 型 自动 匹配 的 实现 来 讲 第 一 步 也 是 寻找 bw 中 需要 
依赖 注入 的 属性 ， 然 后 遇 历 这 些 属 性 并 寻找 类 型 匹配 的 bean， 其 中 最 复 
杂 的 就 是 寻找 类 型 匹配 的 bean。 同 时 ，Spring 中 提供 了 对 集合 的 类 型 注 
入 的 文 持 ， 如 使 用 注解 的 方式 : 

















@Autowired 
private List<Test> tests; 

Spring 将 会 把 所 有 与 Test 匹 配 的 类 型 找 出 来 并 注入 到 tests 属 性 中 ， 
正 是 由 于 这 一 因素 ， 所 以 在 autowireByType 函数 中 ， 新 建 了 局 部 遍历 
autowiredBeanNames， 用 于 存储 所 有 依赖 的 pean， 如 果 只 是 对 非 集合 类 
的 属性 注入 来 说 ， 此 属性 并 无 用 处 。 

对 于 寻找 类 型 匹配 的 逻辑 实现 封装 在 了 resolveDependency 函 数 中 。 

DefaultListableBeanFactory.java 

public Object resolveDependency(DependencyDescriptor descriptor, 
String beanName, 

Set<String> autowiredBeanNames, TypeConverter typeConverter) 
throws 


BeansException { 


descriptor.initParameterNameDiscovery(getParameterNameDiscoverer()); 
if (descriptor.getDependencyType().equals(ObjectFactory.class)) { 
/ObjectFactory 类 注入 的 特殊 处 理 
return new DependencyObjectFactory(descriptor, beanName); 
} 
else if 
(descriptor.getDependencyType().equals(javaxInjectProviderClass)) { 
//javaxInjectProviderClass 类 注入 的 特殊 处 理 
beanName); 
return new 
DependencyProviderFactory().createDependencyProvider (descriptor, 
} 


else { 


/通用 处 理 逻 辑 
return doResolveDependency(descriptor, 
descriptor.getDependencyType(), 


beanName, autowiredBeanNames, typeConverter); 


} 

protected Object doResolveDependency(DependencyDescriptor 
descriptor, Class<?> type, 

String beanName, 

Set<String> autowiredBeanNames, TypeConverter typeConverter) 
throws 


BeansException { 


/* 

* 用 于 文 持 Spring 中 新 增 的 注解 @Value 
$i 
Object value = 


getAutowireCandidateResolver().getSuggestedV alue(descriptor); 
if (value != null) { 
if (value instanceof String) { 
String strVal = resolveEmbeddedValue((String) value); 
BeanDefinition bd = (beanName != null && 
containsBean(beanName) ? 
getMergedBeanDefinition(beanName) : null); 
value = evaluateBeanDefinitionString(strVal, bd); 
} 


TypeConverter converter = (typeConverter != null ? typeConverter 


getTypeConverter()); 
return converter.convertIfNecessary(value, type); 
j 
ITUR EIE c ENCIMA, DU mS EEG IER D 
/属性 是 数组 类 型 
if (type.isArray()) { 
Class<?> componentType = type.getComponentT ype(); 
/根据 属性 类 型 找到 beanFacotry 中 所 有 类 型 的 匹配 bean， 
/返回 值 的 构成 为 : key= 匹 配 的 beanName,value=beanName 对 
应 的 实例 化 后 的 bean( 通 过 
getBean(beanName) 返 回 ) 
Map<String, Object> matchingBeans = 
findAutowireCandidates(beanName， 
componentType, descriptor); 
if (matchingBeans.isEmpty()) { 
/如 果 autowire 的 require 属 性 为 true 而 找到 的 匹配 项 却 为 空 则 
只 能 抛 出 异常 
if (descriptor.isRequired()) { 
raiseNoSuchBeanDefinitionException(componentType, 
"array of " + 
componentType.getName(), descriptor); 
} 
return null; 
} 
if (autowiredBeanNames != null) { 


autowiredBeanNames.addAll(matchingBeans.keySet()); 


TypeConverter converter = (typeConverter != null ? typeConverter 


get TypeConverter()); 
/通过 转换 器 将 bean 的 值 转换 为 对 应 的 type 类 型 
return converter.convertIfNecessary(matchingBeans.values(), 
type); 
j 
/属性 是 Collection 类 型 
else if (Collection.class.isAssignableFrom(type) && 
type.isInterface()) { 
Class<?> elementType = descriptor.getCollectionType(); 
if (elementT ype == null) { 
if (descriptor.isRequired()) { 
throw new FatalBeanException("No element type declared 
for 
collection [" + type.getName() + "]"); 


return null; 


Map<String, Object> matchingBeans = 
findAutowireCandidates(beanName, 
elementType, descriptor); 
if (matchingBeans.isEmpty()) { 
if (descriptor.isRequired()) { 
raiseNoSuchBeanDefinitionException(elementType, 
"collection of " 


+ elementType.getName(), descriptor); 


} 
return null; 
} 
if (autowiredBeanNames != null) { 
autowiredBeanNames.addAll(matchingBeans.keySet()); 
j 
TypeConverter converter = (typeConverter != null ? 
typeConverter : 
getT'ypeConverter()); 
return converter.convertIf Necessary(matchingBeans.values(), 
type); 
j 
/属性 是 Map 类 型 
else if (Map.class.isAssignableFrom(type) && type.isInterface()) { 





Class<?> keyType = descriptor.getMapKeyType(); 
if (keyType == null || !String.class.isAssignableFrom(keyType)) 


if (descriptor.isRequired()) { 
throw new FatalBeanException("Key type [" + keyType + 
"] of map 
[" + type.getName() + 
"| must be assignable to [java.lang.String |"); 
} 
return null; 
} 
Class<?> valueType = descriptor.getMap ValueType(); 
if (valueType == null) { 


if (descriptor.isRequired()) { 
throw new FatalBeanException(" No value type declared 
for map [" 
+ type.getName() + "|"); 
} 
return null; 
} 
Map<String, Object> matchingBeans = 
findAutowireCandidates(beanName, 
valueType, descriptor); 
if (matchingBeans.isEmpty()) { 
if (descriptor.isRequired()) { 
raiseNoSuchBeanDefinitionException(valueType, "map 
with value 
type " + valueType.getName(), descriptor); 
j 
return null; 
j 
if (autowiredBeanNames !- null) 1 
autowiredBeanNames.addAll(matchingBeans.keySet()); 
i 
return matchingBeans; 
jelse { 
Map<String, Object> matchingBeans = 
findAutowireCandidates(beanName, type, 
descriptor); 


if (matchingBeans.isEmpty()) { 


if (descriptor.isRequired()) { 
raiseNoSuchBeanDefinitionException(type, "", descriptor); 
j 
return null; 
i 
if (matchingBeans.size() > 1) { 
String primaryBeanName = 
determinePrimaryCandidate(matchingBeans, 
descriptor); 
if (primaryBeanName == null) { 
matching bean but found " + 
throw new NoSuchBeanDefinitionException(type, 
"expected single 
matchingBeans.size() + ": " + matchingBeans.keySet()); 
} 
if (autowiredBeanNames != null) { 
autowiredBeanNames.add(primaryBeanName); 
} 
return matchingBeans.get(primaryBeanName); 
j 
/已 经 可 以 确定 只 有 一 个 匹配 项 
next(); 
Map.Entry<String, Object> entry = matchingBeans.entrySet(). 
iterator(). 
if (autowiredBeanNames !- null) { 


autowiredBeanNames.add(entry.getKey()); 


return entry.getValue(); 


} 

PRA AY DE CUT UPS, EG SE A AT a EAT ET. "DA 
解析 器 没有 成 功 解析 ， 那 么 可 能 是 使 用 默认 的 解析 器 没有 做 任何 处 理 ， 
或 者 是 使 用 了 自 定 义 的 解析 器 ， 但 是 对 于 集合 等 类 型 来 说 并 不 在 解析 范 
围 之 内 ， 上 所 以 再 次 对 不 同类 型 进行 不 同情 况 的 处 理 ， 虽 说 对 于 不 同类 型 
处 理 方式 不 一 致 ， 但 是 大 致 的 思路 还 是 很 相似 的 ， 所 以 函数 中 只 对 数组 
类 型 进行 了 详细 地 注释 。 

3. applyPropertyValues 

程序 运行 到 这 里 ， 已 经 完成 了 对 所 有 注入 属性 的 获取 ， 但 是 获取 的 
属性 是 以 PropertyValues 形 式 存在 的 ， 还 并 没有 应 用 到 已 经 实例 化 的 bean 
中 ， 这 一 工作 是 在 applyPropertyValues 中 。 

protected void applyPropertyValues(String beanName, BeanDefinition 

















mbd, BeanWrapper bw, 
Property Values pvs) 1 
if (pvs == null || pvs.isEmpty()) { 
return; 
j 
MutableProperty Values mpvs = null; 
List<PropertyValue> original; 
if (System.getSecurityManager()!- null) { 
if (bw instanceof BeanWrapperlImpl) { 
((BeanWrapperImpl) 
bw).setSecurityContext(getAccessControlContext()); 
j 


让 (pvs instanceof MutablePropertyValues) { 
mpvs = (MutableProperty Values) pvs; 
// 如 果 mpvs 中 的 值 已 经 被 转换 为 对 应 的 类 型 那么 可 以 直接 设置 
到 beanwapper 中 
if (mpvs.isConverted()) { 
// Shortcut: use the pre-converted values as-is. 
try { 
bw.setProperty Values(mpvs); 
return; 
j 
catch (BeansException ex) 1 
throw new BeanCreationException( 
mbd.getResourceDescription(), beanName, "Error setting 


property values", ex); 


j 
original = mpvs.getProperty ValueList(); 

jelse 1 
/如 果 pvs 并 不 是 使 用 MutablePropertyValues 封 装 的 类 型 ， 那 么 

直接 使 用 原始 的 属性 获取 方法 

original = Arrays.asList(pvs.getPropertyValues()); 

} 

TypeConverter converter = getCustomT ypeConverter(); 

if (converter == null) { 
converter = bw; 

} 

1/ 获取 对 应 的 解析 器 


BeanDefinitionValueResolver valueResolver = new 
BeanDefinition ValueResolver(this, 

beanName, mbd, converter); 

// Create a deep copy, resolving any references for values. 

List<Property Value> deepCopy = new ArrayList<Property Value> 
(original.size()); 

boolean resolveNecessary - false; 

/ Di RTE, E Je T Te RAE SEED IS Je PEAY Se 

for (Property Value pv : original) 1 

if (pv.isConverted()) 1 





deepCopy.add(pv); 
jelse 1 

String propertyName = pv.getName(); 

Object originalValue = pv.getValue(); 

Object resolvedValue = 
valueResolver.resolveV alueIf Necessary(pv, 

originalValue); 

Object convertedValue = resolvedV alue; 


boolean convertible = bw.isWritableProperty(propertyName) 


&& 
!PropertyAccessorUtils.isNestedOrIndexedProperty 
(propertyName); 
if (convertible) { 
bw, converter); 
convertedV alue = convertForProperty(resolvedValue, 
propertyName, 


} 


if (resolvedValue == originalValue) { 

if (convertible) { 

pv.setConvertedValue(convertedValue); 

} 
deepCopy.add(pv); 

} 
else if (convertible && original Value instanceof 
TypedStringValue && 

!((TypedString Value) original Value).isDynamic() && 

(convertedValue))) { 

!(convertedValue instanceof Collection || ObjectUtils.isArray 
pv.setConvertedValue(converted Value); 
deepCopy.add(pv); 

} 
else { 
resolveNecessary = true; 


deepCopy.add(new Property Value(pv, convertedV alue)); 


j 
if (mpvs != null && !resolveNecessary) 1 
mpvs.setConverted(); 
} 
try { 
bw.setProperty Values(new MutableProperty Values(deepCopy)); 
} 


catch (BeansException ex) { 


throw new BeanCreationEXception( 
values", ex); 


mbd.getResourceDescription(), beanName, "Error setting property 


} 
} 
5.7.4 初始 化 bean 


大 家 应 该 记得 在 bean 配 置 时 bean 中 有 一 个 init-method 的 属性 ， 这 个 
属性 的 作用 是 在 bean 实 例 化 前 调用 init-method 指 定 的 方法 来 根据 用 户 业 
务 进行 相应 的 实例 化 。 我 们 现在 就 已 经 进入 这 个 方法 了 ， 首 先 看 一 下 这 
个 方法 的 执行 位 置 ，Spring 中 程序 已 经 执行 过 bean 的 实例 化 ， 并 且 进 行 
了 属性 的 填充 ， 而 就 在 这 时 将 会 调用 用 户 设 定 的 初始 化 方法 。 


protected Object initializeBean(final String beanName, final Object 





bean, RootBean 
Definition mbd) { 
if (System.getSecurityManager() != null) { 
AccessController.doPrivileged(new PrivilegedAction<Object>() { 
public Object run() 1 
invokeAwareMethods(beanName, bean); 
return null; 
j 
}, getAccessControlContext()); 
} 
else { 
/对 特殊 的 bean 处 理 :Aware、BeanClassLoaderAware、 
BeanFactoryAware 


invokeAwareMethods(beanName, bean); 


} 
Object wrappedBean = bean; 
if (mbd == null || !Imbd.isSynthetic()) { 
ILH Ja AeIE at 
wrappedBean = 
applyBeanPostProcessorsBeforeInitialization(wrappedBean， 
beanName); 
} 
try { 
// 油 活用 户 目 定义 的 init 方 法 
invokeInitMethods(beanName, wrappedBean, mbd); 
} 
catch (Throwable ex) { 
throw new BeanCreationException( 
(mbd != null ? mbd.getResourceDescription() : null), 
beanName, "Invocation of init method failed", ex); 
} 
if (mbd == null || !Imbd.isSynthetic()) { 
/后 处 理 器 应 用 
wrappedBean = 
applyBeanPostProcessorsA fterInitialization(wrappedBean, 
beanName); 
} 
return wrappedBean; 
} 
虽然 说 此 函数 的 主要 目的 是 进行 客户 设 定 的 初始 化 方法 的 调用 ， 但 
是 除 此 之 外 还 有 些 其 他 必要 的 工作 。 





1. 激活 Aware 方 法 
在 分 析 其 原理 之 前 ， 我 们 先 了 解 一 下 Aware 的 使 用 。Spring 中 提供 
一 些 Aware 相 关 接 口 ， 比 如 BeanFactoryAware、 
ApplicationContextAware、ResourceLoaderAware、ServletContextAware 
等 ， 实 现 这 些 Aware 接口 的 bean 在 被 初始 之 后 ， 可 以 取得 一 些 相 对 应 
的 资源 ， 例 如 实现 BeanFactoryAware 的 bean 在 初始 后 ， Spring 容器 将 
会 注入 BeanFactory 的 实例 ， 而 实现 ApplicationContextAware 的 bean， 在 
bean 被 初始 后 ， 将 会 被 注入 ApplicationContext 的 实例 等 。 我 们 首先 通过 
示例 方法 来 了 解 一 下 Aware 的 使 用 。 
(1) 定义 普通 bean。 
public class Hello { 
public void say() { 
System.out.printIn("hello"); 


j 
(2) 定义 BeanFactoryAware 类 型 的 bean。 
public class Test implements BeanFactoryA ware 1 
private BeanFactory beanFactory; 
/声明 bean 的 时 候 Spring 会 自动 注入 BeanFactory 
@Override 
public void setBeanFactory(BeanFactory beanFactory) throws 
BeansException { 
this.beanFactory = beanFactory; 
} 
public void testAware() { 
/通过 hello 这 个 bean id 从 beanFactory 获 取 实 例 
Hello hello = (Hello) beanFactory.getBean("hello"); 


hello.say(); 


j 
(3) 使 用 main 方 法 测试 。 
public static void main(String[] s) { 
ApplicationContext ctx = new 
ClassPathXmlApplicationContext("applicationContext.xml"); 
Test test = (Test) ctx.getBean("test"); 


test.testA ware(); 


} 
运行 测试 类 ， 控 制 台 输出 : 
hello 


按照 上 面 的 方法 我 们 可 以 获取 到 Spring 中 BeanFactory， 并 且 可 以 根 
据 BeanFactory 获 取 所 有 bean， 以 及 进行 相关 设置 。 当 然 还 有 其 他 Aware 
的 使 用 方法 都 大 同 小 异 ， 看 一 下 Spring 的 实现 方式 ， 相 信 读 者 便 会 使 用 
Tg 
private void invokeAwareMethods(final String beanName, final Object 
bean) { 
if (bean instanceof Aware) { 
if (bean instanceof BeanNameAware) { 
((BeanNameAware) bean).setBeanName(beanName); 
} 
if (bean instanceof BeanClassLoaderA ware) { 
((BeanClassLoaderA ware) 
bean).setBeanClassLoader(getBeanClassLoader()); 
} 


if (bean instanceof BeanFactoryAware) { 


Factory.this); 
((BeanFactoryA ware) bean).setBeanFactory(AbstractAutowire 
CapableBean 
} 


} 

代码 简单 得 已 经 没有 什么 好 说 的 了 。 读 者 可 以 自己 答 试 使 用 别 的 
Aware， 都 比较 简单 。 

2. 处 理 器 的 应 用 

BeanPostProcessor 相 信 大 家 都 不 陌生 ， 这 是 Spring 中 开放 式 架 构 中 
一 个 必 不 可 少 的 亮点 ， 给 用 户 充 足 的 权限 去 更 改 或 者 扩展 Spring ， 而 除 
了 BeanPostProcessor 外 还 有 很 多 其 他 的 PostProcessor， 当 然 大 部 分 都 是 
以 此 为 基础 ， 继 承 自 BeanPostProcessor。BeanPostProcessor 的 使 用 位 置 
就 是 这 里 ， 在 调用 客户 自 定义 初始 化 方法 前 以 及 调用 自 定义 初始 化 方法 
后 分 别 会 调用 BeanPostProcessor 的 postProcessBeforeInitialization 和 
postProcessAfterInitialization 方 法 ， 使 用 户 可 以 根据 自己 的 业务 需求 进行 
啊 应 的 处 理 。 


public Object applyBeanPostProcessorsBeforelnitialization(Object 








existingBean, String 
beanName) 
throws BeansException 1 
Object result = existingBean; 
for (BeanPostProcessor beanProcessor : getBeanPostProcessors()) 1 
result = beanProcessor.postProcessBeforelnitialization(result, 
beanName); 
if (result == null) ( 


return result; 


} 
return result; 
} 
public Object applyBeanPostProcessorsA fterInitialization(Object 
existingBean, String 
beanName) 
throws BeansException 1 
Object result = existingBean; 
for (BeanPostProcessor beanProcessor : getBeanPostProcessors()) 1 
result = beanProcessor.postProcessA fterInitialization(result, 
beanName); 
if (result == null) ( 


return result; 


} 
return result; 
} 
3. 激活 自 定 义 的 init 方 法 
客户 定制 的 初始 化 方法 除了 我 们 熟知 的 使 用 配置 init-method 外 ， 还 
有 使 自 定义 的 bean 实 现 InitializingBean 接 口 ， 并 在 afterPropertiesSet 中 实 
现 自 己 的 初始 化 业务 逻辑 。 
init-method 与 afterPropertiesSet 都 是 在 初始 化 bean 时 执行 ， 执 行 顺序 
是 afterPropertiesSet 先 执行 ， 而 init-method 后 执行 。 
在 pvokeInitMethods 方 法 中 就 实现 了 这 两 个 步骤 的 初始 化 方法 调 
FA. 


protected void invokeInitMethods(String beanName, final Object bean, 


RootBeanDefinition mbd) 
throws Throwable { 
/首先 会 检查 是 否 是 mitializingBean， 如 果 是 的 话 需要 调用 


afterPropertiesSet 方 法 








boolean isInitializingBean = (bean instanceof InitializingBean); 
if (isInitializingBean && (mbd == null || !mbd.isExternally 
ManagedInitMethod 
("afterPropertiesSet"))) { 
if (logger.isDebugEnabled()) { 
logger.debug("Invoking afterPropertiesSet() on bean with 
name ”十 
beanName + """); 
if (System.getSecurityManager() != null) { 
try { 
<Object>() { 
AccessController.doPrivileged(new 
PrivilegedExceptionAction 
public Object run() throws Exception { 
((InitializingBean) bean).afterPropertiesSet(); 
return null; 
} 
}, getAccessControlContext()); 
} 
catch (PrivilegedActionException pae) { 
throw pae.getException(); 


}else { 
/属性 初始 化 后 的 处 理 
((InitializingBean) bean).afterPropertiesSet(); 


} 

if (mbd != null) { 
String initMethodName = mbd.getInitMethodName(); 
if (initMethodName != null && !(isInitializingBean && 

"afterPropertiesSet". 
equals(initMethodName)) && 
!mbd.isExternallyManagedInitMethod(initMethodName)) { 

/调用 目 定 义 初始 化 方法 


invokeCustomInitMethod(beanName, bean, mbd); 


} 


5.7.5 注册 DisposableBean 

Spring 中 不 但 提供 了 对 于 初始 化 方法 的 扩展 入 口 ， 同 样 也 提供 了 销 
毁 方 法 的 扩展 入 口 ， 对 于 销毁 方法 的 扩展 ， 除 了 我 们 熟知 的 配置 属性 
destroy-method 方 法 外 ， 用 户 还 可 以 注册 后 处 理 器 
DestructionAwareBeanPostProcessor 来 统一 处 理 bean 的 销毁 方法 ， 代 码 如 
下 

protected void registerDisposableBeanIfNecessary(String beanName, 
Object bean， 

RootBeanDefinition mbd) { 


AccessControlContext acc = (System.getSecurityManager() != null ? 


getAccess 
ControlContext() : null); 
if (!mbd.isPrototype() && requiresDestruction(bean, mbd)) { 
if (mbd.isSingleton()) { 
f* 
* 单 例 模式 下 注册 需要 销毁 的 bean， 此 方法 中 会 处 理 实 现 
DisposableBean 的 bean， 
* 并 且 对 所 有 的 bean 使 用 
DestructionAwareBeanPostProcessors 处 理 
* DisposableBean DestructionA wareBeanPostProcessors, 
an 
registerDisposableBean(beanName, 
new DisposableBeanAdapter(bean, beanName, mbd, 
getBeanPost 
Processors(), acc)); 
jelse { 
f* 
* 上 自 定 义 scope 的 处 理 
a 
Scope scope = this.scopes.get(mbd.getScope()); 
if (scope == null) { 
throw new IllegalStateException("No Scope registered for 
scope ” 
+ mbd.getScope() + """); 
i 
scope.registerDestructionCallback(beanName, 


new DisposableBeanAdapter(bean, beanName, mbd, 


getBeanPost 


Processors(), acc)); 


经 过 前 面 几 章 的 分 析 ， 相 信 大 家 已 经 对 Spring 中 的 容器 功能 有 了 简 
单 的 了 解 ， 在 前 面 的 章节 中 我 们 一 直 以 BeanFacotry 接 口 以 及 它 的 默认 实 
现 类 XmlBeanFactory 为 例 进行 分 析 ， 但 是 ， Spring 中 还 提供 了 另 一 个 接 
口 ApplicationContext， 用 于 扩展 BeanFacotry 中 现 有 的 功能 。 

ApplicationContext 和 BeanFacotry 两 者 都 是 用 于 加 载 Bean 的 ， 但 是 相 
比 之 下 ，Application Context 提 供 了 更 多 的 扩展 功能 ， 简 单一 点 说 : 
ApplicationContext 包 含 BeanFactory 的 所 有 功能 。 通 党 建议 比 
BeanFactory 优先 ， 除 非 在 一 些 限 制 的 场合 ， 比 如 字 节 长 度 对 内 存 有 很 
大 的 影响 时 (Applet) 。 绝 大 多 数 “ 典 型 的 ”企业 应 用 和 系统 ， 
ApplicationContext 就 是 你 需要 使 用 的 。 

那么 究竟 ApplicationContext 比 BeanFactory 多 出 了 哪些 功能 呢 ? 还 
需要 我 们 进一步 的 探索 。 首 先 我 们 来 看 看 使 用 两 个 不 同 的 类 去 加 载 配置 
文件 在 写法 上 的 不 同 。 

使 用 BeanFactory 方 式 加 载 XML 。 


BeanFactory bf = new XmlBeanFactory(new 





ClassPathResource("beanFactoryTest.xml")); 
^it Hl ApplicationContext77 XJ £& XML 。 
ApplicationContext bf = new 


ClassPathXmlApplicationContext("beanFactory Test.xml"); 


同样 ， 我 们 还 是 以 ClassPathXmlApplicationContext 作 为 切入 点 ， 开 
台 对 整体 功能 进行 分 析 。 
public ClassPathXmlApplicationContext(String configLocation) throws 


BeansException { 
this(new String[] {configLocation}, true, null); 


} 
public ClassPathXmlApplicationContext(String[] configLocations, 


boolean refresh, 
ApplicationContext parent) throws BeansException { 


super(parent); 
setConfigLocations(configLocations); 


if (refresh) { 
refresh(); 


} 
设置 路 径 是 必 不 可 少 的 步 又，ClassPathXmlApplicationContext 中 可 


以 将 配置 文件 路 径 以 数组 的 方式 传 入 ，ClassPathXmlApplicationContext 
可 以 对 数组 进行 解析 并 进行 加 载 。 而 对 于 解析 及 功能 实现 都 在 refresh() 


中 实现 。 
6.1 设置 配置 路 径 

在 ClassPathXmlApplicationContext 中 支持 多 个 配置 文件 以 数组 方式 
同时 传 入 : 


public void setConfigLocations(String[] locations) { 





if (locations != null) { 
Assert.noNullElements(locations, "Config locations must not be 


null"); 
this.configLocations = new String[locations.length]; 
for (int i = 0; i < locations.length; i++) { 
// 解 析 给 定 路 径 


this.configLocations[i] = resolvePath(locations[i ]).trim(); 


j 
else { 


this.configLocations - null; 


} 
此 函数 主要 用 于 解析 给 定 的 路 径 数组 ， 当 然 ， 如 果 数 组 中 包含 特殊 
符号 ， 如 ${var}， 那 么 在 resolvePath 中 会 搜寻 匹配 的 系统 变量 并 替换 。 


6.2 扩展 功能 





设置 了 路 径 之 后 ， 便 可 以 根据 路 径 做 配置 文件 的 解析 以 及 各 种 功能 
的 实现 了 。 可 以 说 refresh 函数 中 包含 了 几乎 ApplicationContext 中 提供 
的 全 部 功能 ， 而 且 此 函数 中 逻辑 非常 清晰 明了 ， 使 我 们 很 容易 分 析 对 应 
HEURE SR. 
public void refresh() throws BeansException, IllegalStateException 1 
synchronized (this.startupShutdownMonitor) 1 
1/ 准备 刷新 的 上 下 文 环境 
prepareRefresh(); 
// Tell the subclass to refresh the internal bean factory. 
/初始 化 BeanFactory， 并 进行 XML 文件 读 取 
ConfigurableListableBeanFactory beanFactory = 


obtainFreshBeanFactory(); 


// Prepare the bean factory for use in this context. 
/对 BeanFactory 进 行 各 种 功能 填充 


prepareBeanFactory(beanFactory); 


try { 


subclasses. 


// Allows post-processing of the bean factory in context 


I| FRB ht FTES I E] Ab ER 
postProcessBeanFactory(beanFactory); 

I Bi & Ft BeanFactory tb 8 28 
invokeBeanFactoryPostProcessors(beanFactory); 


/注册 拦截 Bean 创 建 的 Bean 处 理 器 ,这 里 只 是 注册 ， 真 正 的 调 


用 是 在 getBean 时 候 


化 处 理 


registerBeanPostProcessors(beanFactory); 


/ 为 上 下 文 初始 化 Message 源 ， 即 不 同 语言 的 消息 体 ， 国 际 


initMessageSource(); 


// Initialize event multicaster for this context. 


/ 初始 化 应 用 消息 广播 器 ， 并 放 


入 “applicationEventMulticaster”bean 中 


器 中 


initApplicationEventMulticaster(); 

// Initialize other special beans in specific context subclasses. 
/ 留 给 子 类 来 初始 化 其 它 的 Bean 

onRefresh(); 

// Check for listener beans and register them. 


/在 所 有 注册 的 bean 中 查找 Listener bean， 注 册 到 消息 广播 


registerListeners(); 
// Instantiate all remaining (non-lazy-init) singletons. 
/ 初始 化 剩 下 的 单 实例 〈 非 惰性 的 ) 
finishBeanFactoryInitialization(beanFactory); 
// Last step: publish corresponding event. 
/完成 刷新 过 程 ， 通 知 生命 周 期 处 理 器 lifecycleProcessor Jil 
新 过 程 ， 同 时 发 出 
ContextRefreshEvent 通 知 别人 
finishRefresh(); 
j 
catch (BeansException ex) 1 


// Destroy already created singletons to avoid dangling 


resources. 
destroyBeans(); 
// Reset 'active' flag. 
cancelRefresh(ex); 
// Propagate exception to caller. 
throw ex; 

j 
j 
j 


下 面 概括 一 下 ClassPathXmlApplicationContext 初 始 化 的 步骤 ， 并 从 
中 解释 一 下 它 为 我 们 提供 的 功能 。 
(1) 初始 化 前 的 准备 工作 ， 例 如 对 系统 属性 或 者 环境 变量 进行 准 
备 及 验证 。 
在 某 种 情况 下 项 目的 使 用 需要 读 取 某 些 系统 变量 ， 而 这 个 变量 的 设 
置 很 可 能 会 影响 着 系统 的 正确 性 ， 那 么 ClassPathXmlApplicationContext 











为 我 们 提供 的 这 个 准备 函数 惑 显得 非常 必要 ， 它 可 以 在 Spring 局 动 的 时 
候 提前 对 必须 的 变量 进行 存在 性 验证 。 
(2) 初始 化 BeanFactory， 并 进行 XML 文件 读 取 。 

之 前 有 提 到 ClassPathXmlApplicationContext 包 含 着 BeanFactory 所 提 
供 的 一 切 特征 ， 那 么 在 这 一 步骤 中 将 会 复 用 BeanFactory 中 的 配置 文件 
读 取 解析 及 其 他 功能 ， 这 一 步 之 后 ， ClassPathXmlApplicationContext 实 
际 上 就 已 经 包含 了 BeanFactory 所 提供 的 功能 ， 也 就 是 可 以 进行 Bean 的 
提取 等 基础 操作 了 。 

(3) 对 BeanFactory 进 行 各 种 功能 填充 。 

@Qualifier 与 @Autowired 应 该 是 大 家 非常 熟悉 的 注解 ， 那 么 这 两 个 

注解 正 是 在 这 一 步骤 中 增加 的 文 持 。 
(4) 子 类 敌 盖 方法 做 额外 的 处 理 。 

Spring 之 所 以 强大 ， 为 世人 所 推 染 ， 除 了 它 功 能 上 为 大 家 提供 了 便 
例外 ， 还 有 一 方面 是 它 的 完美 染 构 ， 开 放 式 的 架构 让 使 用 它 的 程序 员 很 
容易 根据 业务 需要 扩展 已 经 存在 的 功能 。 这 种 开放 式 的 设计 在 Spring 中 
随处 可 见 ， 例 如 在 本 例 中 就 提供 了 一 个 空 的 函数 实现 postProcess 
BeanFactory 来 方便 程序 员 在 业务 上 做 进一步 扩展 。 

(5) 激活 各 种 BeanFactory 处 理 器 。 

(6) 注册 拦截 bean 创 建 的 bean 处 理 器 ， 这 里 只 是 注册 ， 真 正 的 调 
用 是 在 getBean 时 候 。 

CÓ 为 上 下 文 初始 化 Message 源 ， 即 对 不 同 语言 的 消息 体 进行 国际 
化 处 理 : 

(8) JA NER RJ dius. JP 
A“applicationEventMulticaster”bean# 。 

(9) 留 给 子 类 来 初始 化 其 他 的 bean。 

(10) 在 所 有 注册 的 bean 中 查找 listener bean， 注 册 到 消息 广播 器 














C11) 初始 化 剩 下 的 单 实例 〈 非 惰性 的 ) 。 
(12) 完成 刷新 过 程 ， 通 知 生命 周期 处 理 器 lifecycleProcessor 刷 新 
过 程 ， 同 时 发 出 Context RefreshEvent 通 知 别 人 。 


6.3 X^ Hr B 


prepareRefresh 函 数 主 要 是 做 些 准 备 工 作 ， 例 如 对 系统 属性 及 环境 变 
量 的 初始 化 及 验证 。 

protected void prepareRefresh() { 

this.startupDate = System.currentTimeMillis(); 

synchronized (this.activeMonitor) { 
this.active = true; 

} 

if (logger.isInfoEnabled()) { 
logger.info("Refreshing " + this); 

} 
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initPropertySources(); 

/验证 需要 的 属性 文件 是 否 都 已 经 放 入 环境 中 

getEnvironment().validateRequiredProperties(); 

} 

网 上 有 人 说 其 实 这 个 函数 没什么 用 ， 因 为 最 后 两 句 代 人 码 才 是 最 为 关 
键 的 ， 但 是 却 没 有 什么 逻辑 处 理 ，initPropertySources 是 空 的 ， 没 有 任何 
逻辑 ， 而 getEnvironment().validateRequiredProperties 也 因为 没有 需要 验 
证 的 属性 而 没有 做 任何 处 理 。 其 实 这 都 是 因为 没有 彻底 理解 才 会 这 么 
说 ， 这 个 函数 如 果 用 好 了 作用 还 是 挺 大 的 。 那 么 ， 该 怎么 用 呢 ? S 
探索 下 各 个 函数 的 作用 。 


(1) initPropertySources 正 符合 Spring 的 开放 式 结 构 设 计 ， 给 用 户 最 
大 扩展 Spring 的 能 力 。 用 户 可 以 根据 自身 的 需要 重 写 initPropertySources 
方法 ， 并 在 方法 中 进行 个 性 化 的 属性 处 理 及 设置 。 
(2) validateRequiredProperties 则 是 对 属性 进行 验证 ， 那 么 如 何 验 
证 呢 ? 我 们 举 个 融合 两 名 代码 的 小 例子 来 帮助 大 家 理解 。 
假如 现在 有 这 样 一 个 需求 ， 工 程 在 运行 过 程 中 用 到 的 某 个 设置 〈 例 
如 VAR) 是 从 系统 环境 变量 中 取得 的 ， 而 如 果 用 户 没有 在 系统 环境 变量 
中 配置 这 个 参数 ， 那 么 工程 可 能 不 会 工作 。 这 一 要 求 可 能 会 有 各 种 各 样 
的 解决 办 法 ， 当 然 ， 在 Spring 中 可 以 这 样 做 ， 你 可 以 直接 修改 Spring 的 
源码 ， 例 如 修改 ClassPathXmlApplicationContext。 当 然 ， 最 好 的 办 法 还 
是 对 源码 进行 扩展 ， 我 们 可 以 自 定义 类 : 
public class MyClassPathXmlApplicationContext extends 




















ClassPathXmlApplicationContext{ 
public MyClassPathXmlApplicationContext(String... 
configLocations ){ 
super(configLocations); 
j 
protected void initPropertySources() 1 
/添加 验证 要 求 
getEnvironment().setRequiredProperties("VAR"); 


} 

我 们 目 定 义 了 继承 自 ClassPathXmlApplicationContext 的 
MyClassPathXmlApplicationContext， 并 重 写 了 initPropertySources 方 
法 ， 在 方法 中 添加 了 我 们 的 个 性 化 需求 ， 那 么 在 验证 的 时 候 也 就 是 程序 
走 到 getEnvironment().validateRequiredProperties() 代 人 码 的 时 候 ， 如 果 系 统 
并 没有 检测 到 对 应 VAR 的 环境 变量 ， 那 么 将 抛 出 异常 。 当 然 我 们 还 需 


要 在 使 用 的 时 候 蔡 换 挥 原 有 的 ClassPathXmlApplicationContext: 
public static void main(String[] args) { 
ApplicationContext bf = new MyClassPathXmlA pplicationContext 
("test/customtag/ 
test.xml"); 


User user-(User) bf.getBean( testbean"); 


6.4 i BeanFactor 


obtainFreshBeanFactory 方法 从 字面 理解 是 获取 BeanFactory。 之 前 
有 说 过 ， Application Context 是 对 BeanFactory 的 功能 上 的 扩展 ， 不 但 包 
含 了 BeanFactory 的 全 部 功能 更 在 其 基础 上 添加 了 大 量 的 扩展 应 用 ， 那 么 
obtainFreshBeanFactory 正 是 实现 BeanFactory 的 地 方 ， 也 就 是 经 过 了 这 个 
水 数 后 ApplicationContext 束 已 经 拥有 了 BeanFactory 的 全 部 功能 。 
protected ConfigurableListableBeanFactory obtainFreshBeanFactory() { 
// 初 始 化 BeanFactory， 并 进行 XML 文 件 读 取 , 并 将 得 到 的 
BeanFacotry 记 录 在 当前 实体 的 属性 中 
refreshBeanFactory(); 
/返回 当前 实体 的 beanFactory 属 性 
ConfigurableListableBeanFactory beanFactory = getBeanFactory(); 
if (logger.isDebugEnabled()) { 
logger.debug(" Bean factory for " + getDisplayName() + ": " + 








beanFactory); 


} 


return beanFactory; 


方法 中 将 核心 实现 委托 给 了 refreshBeanFactory: 
@Override 
protected final void refreshBeanFactory() throws BeansException { 
if (hasBeanFactory()) { 
destroyBeans(); 
closeBeanFactory(); 
} 
try { 
/创建 DefaultListableBeanFactory 
DefaultListableBeanFactory beanFactory = createBeanFactory(); 
/为 了 序列 化 指定 id， 如 果 需 要 的 话 ,让 这 个 BeanFactory 从 id 反 
序列 化 到 BeanFactory 对 象 
beanFactory.setSerializationId(getId()); 
/ÉtlilbeanFactory,. WAHRE, UIEN jo VE TR gs lA) A I 
的 不 同 定 义 的 对 象 以 及 循环 依赖 以 及 
/设置 @Autowired 和 @Qualifier 注解 解析 器 


QualifierAnnotationAutowire 





CandidateResolver 

customizeBeanFactory(beanFactory); 
/初始 化 DodumentReader， 并 进行 XML 文件 读 取 及 解析 
loadBeanDefinitions(beanFactory); 

synchronized (this.beanFactoryMonitor) { 


this.beanFactory = beanFactory; 


} 
catch (IOException ex) { 


throw new ApplicationContextException("I/O error parsing bean 


definition 


source for " + getDisplayName(), ex); 


} 
我 们 详细 分 析 上 面 的 每 个 步骤 。 
(1) 创建 DefaultListableBeanFactory。 
在 介绍 BeanFactory 的 时 候 ， 不 知道 读者 是 否 还 有 印象 ， 声 明 方 式 
JJ: BeanFactory bf = new XmlBeanFactory("beanFactoryTest.xml")， 其 中 
的 XmlBeanFactory 继 承 目 DefaultListableBean Factory， 并 提供 了 
XmlBeanDefinitionReader 类 型 的 reader 属 性 ， 也 就 是 说 
DefaultListableBean Factory 是 容器 的 基础 。 必 须 首 先 要 实例 化 ， 那 么 在 
这 里 就 是 实例 化 DefaultListableBeanFactory 的 步骤 。 
(2) 指定 序列 化 ID。 
(3) 定制 BeanFactory。 
(4) 加 载 BeanDefinition 。 
(5) 使 用 全 局 变量 记录 BeanFactory 类 实例 。 
为 DefaultListableBeanFactory 类 型 的 变量 beanFactory 是 函数 内 的 
局 部 变量 ， 所 以 要 使 用 全 局 变量 记录 解析 结果 。 
6.4.1 定制 BeanFactory 
这 里 已 经 开始 了 对 BeanFactory 的 扩展 ， 在 基本 容器 的 基础 上 ， 增 
加 了 是 否 允 许 履 盖 是 否 允 许 扩展 的 设置 并 提供 了 注解 @Qualifier 和 
@Autowired 的 支持 。 
protected void customizeBeanFactory(DefaultListableBeanFactory 








beanFactory) { 
/如 果 属 性 allowBeanDefinitionOverriding 不 为 空 ， 设 置 给 
beanFactory 对 象 相 应 属性 ， 


/此 属性 的 含义 : 是 否 允 许 履 盖 同 名 称 的 不 同 定义 的 对 象 


if (this.allowBeanDefinitionOverriding != null) { 


beanFactory.setAllowBeanDefinitionOverriding(this.allowBeanDefinitionOve 
} 
//4 4 J VEallowCircularReferences#\ 7J73, ix E Z4beanFactoryXt 
象 相应 属性 ， 
/此 属性 的 含义 : 是 否 人 允许 bean 之 间 存 在 循环 依赖 


if (this.allowCircularReferences != null) { 


beanFactory.setAllowCircularReferences(this.allowCircularReferences); 
} 
/用 于 @Qualifier 和 @Anutowired 
beanFactory.setAutowireCandidateResolver(new 
QualifierAnnotationAutowire 
Candidate Resolver()); 
} 
XT IOV ES ss AU fO VERORUT] IR E R EFT SET A WRN 
为 空 要 进行 设置 ， 但 是 并 没有 看 到 在 哪里 进行 设置 ， 究 苋 这 个 设置 是 在 
DS ETE ANE? AAT, APR TI, Plan: 
public class MyClassPathXmlApplicationContext extends 
ClassPathXmlApplicationContext1 
protected void customizeBeanFactory(DefaultListableBeanFactory 
beanFactory) 1 
super.setAllowBeanDefinitionOverriding(false); 


super.setAllowCircularReferences(false); 


super.customizeBeanFactory(beanFactory); 


} 

设置 完 后 相信 大 家 已 经 对 于 这 两 个 属性 的 使 用 有 所 了 解 ， 或 者 可 以 
回 到 前 面 的 章节 进行 再 一 次 查看 。 对 于 定制 BeanFactory, Spring 还 提 
供 了 另外 一 个 重要 的 扩展 ， 就 是 设置 Autowire CandidateResolver， 在 
bean 加 载 部 分 中 讲解 创建 Bean 时 ， 如 果 采 用 autowireByType 方 式 注入 ， 
那么 默认 会 使 用 Spring 提供 的 a S 而 对 于 
默认 的 实现 并 没有 过 多 的 逻辑 处 理 。 在 这 里 ，Spring 使 用 了 
QualifierAnnotationAutowireCandidateResolver， 设 置 了 这 个 解析 器 后 
Spring 就 可 以 文 持 注解 方式 的 注入 了 。 

在 讲解 根据 类 型 自 定 注入 的 时 候 ， 我 们 说 过 解析 autowire 类 型 时 首 
先 会 调用 方法 : 


Object value = 











get AutowireCandidateResolver().getSuggestedV alue(descriptor); 
因此 我 们 知道 ， 在 QualifierAnnotationAutowireCandidateResolver 中 
会 提供 了 解析 Qualifier 与 Autowire 注 解 的 方法 。 
Qualifier AnnotationAutowireCandidateResolver.java 
public Object getSuggested Value(DependencyDescriptor descriptor) { 
Object value = findValue(descriptor.getAnnotations()); 
if (value == null) { 
MethodParameter methodParam = 
descriptor. getMethodParameter(); 
if (methodParam != null) { 
value = findValue(methodParam.getMethodAnnotations()); 


return value; 


} 
6.4.2 i BeanDefinition 


在 第 一 步 中 提 到 了 将 ClassPathXmlApplicationContext 与 
XmlBeanFactory 创 建 的 对 比 ， 在 实现 配置 文件 的 加 载 功能 中 除了 我 们 在 
第 一 步 中 已 经 初始 化 的 DefaultListableBeanFactory 外 ， 还 需要 
XmlBeanDefinitionReader 来 读 取 XML ， 那 么 在 这 个 步骤 中 首先 要 做 的 
束 是 初始 化 XmlBeanDefinitionReader。 

@Override 

protected void loadBeanDefinitions(DefaultListableBeanFactory 
beanFactory) throws 
BeansException, IOException 1 
I| 7318 E beanFactory fi! && XmlBeanDefinitionReader 
XmlBeanDefinitionReader beanDefinitionReader = new 
XmlBeanDefinitionReader(beanFactory); 
/对 beanDefinitionReader 进 行 环境 变量 的 设置 
beanDefinitionReader.setEnvironment(this. getEnvironment()); 
beanDefinitionReader.setResourceLoader(this); 
beanDefinitionReader.setEntityResolver(new 
ResourceEntityResolver(this)); 
// | BeanDefinitionReaderJtíT ix gi, nf US ss 
initBeanDefinitionReader(beanDefinitionReader); 
loadBeanDefinitions(beanDefinitionReader); 
j 

1E] UR f DefaultListableBeanFactory 4l XmlBeanDefinitionReader/ri 

就 可 以 进行 配置 文件 的 读 取 了 。 


protected void loadBeanDefinitions( XmlBeanDefinitionReader reader) 
throws BeansException, 
IOException 1 
Resource[] configResources = getConfigResources(); 
if (configResources !- null) { 
reader.loadBeanDefinitions(configResources); 
j 
String[] configLocations = getConfigLocations(); 
if (configLocations != null) { 


reader.loadBeanDefinitions(configLocations); 


} 

使 用 XmlBeanDefinitionReader 的 loadBeanDefinitions 方 法 进行 配置 文 
件 的 加 载 机 注册 相信 大 家 已 经 不 陌生 ， 这 完全 吏 是 开始 BeanFactory 的 套 
路 。 因 为 在 XmlBeanDefinitionReader 中 已 经 将 之 前 初始 化 的 
DefaultListableBeanFactory 注 册 进去 了 ， 所 以 XmlBeanDefinitionReader 所 
读 取 的 BeanDefinitionHolder 都 会 注册 到 DefaultListableBeanFactory 中 ， 
也 就 是 经 过 此 步骤 ， 类 型 DefaultListableBeanFactory 的 变量 beanFactory 
已 经 包含 了 所 有 解析 好 的 配置 。 


6.5 功能 扩展 





进入 函数 prepareBeanFactory 前 ，Spring 已 经 完成 了 对 配置 的 解析 ， 
而 ApplicationContext 在 功能 上 的 扩展 也 由 此 展开 。 
protected void prepareBeanFactory(ConfigurableListableBeanFactory 
beanFactory) { 
/设置 beanFactory 的 classLoader 为 当前 context 的 classLoader 


beanFactory.setBeanClassLoader(getClassLoader()); 
// 设 置 beanFactory 的 表达 式 语言 处 理 器 ，Spring3 增 加 了 表达 式 语 
言 的 文 持 ， 
// 默 认可 以 使 用 #{bean.xxx} 的 形式 来 调用 相关 属性 值 。 
beanFactory.setBeanExpressionResolver(new 
StandardBeanExpressionResolver()); 
/为 beanFactory 增 加 了 一 个 默认 的 propertyEditor， 这 个 主要 是 对 
bean 的 属性 等 设置 管理 的 一 
YA 
beanFactory.addPropertyEditorRegistrar(new 
ResourceEditorRegistrar(this, 
getEnvironment())); 
/* 
* 添加 BeanPostProcessor， 
*/ 
beanFactory.addBeanPostProcessor(new 


ApplicationContextA wareProcessor(this)); 


/设置 了 几 个 忽略 目 动 装配 的 接口 
beanFactory.ignoreDependencyInterface(ResourceLoaderA ware.class); 
beanFactory.ignoreDependencylInterface(ApplicationEventPublisherA ware.cli 
beanFactory.ignoreDependencyInterface(MessageSourceA ware.class); 


beanFactory.ignore DependencyInterface(A pplicationContextA ware.class); 


beanFactory.ignoreDependencyInterface(EnvironmentAware.class); 


/设置 了 几 个 目 动 装配 的 特殊 规则 

beanFactory.registerResolvableDependency(BeanFactory.class, 
beanFactory); 

beanFactory.registerResolvableDependency(ResourceLoader.class, 
this); 


beanFactory.registerResolvableDependency(ApplicationEventPublisher.class, 
this); 


beanFactory.registerResolvableDependency(ApplicationContext.class, this); 
/增加 对 AspectJ 的 支持 
if 
(beanFactory.containsBean(LOAD TIME WEAVER BEAN NAMEP)) { 
beanFactory.addBeanPostProcessor(new 
LoadTimeWeaverA wareProcessor(beanFactory)); 
// Set a temporary ClassLoader for type matching. 
beanFactory.setl'empClassLoader(new 
ContextTypeMatchClassLoader (beanFactory. 
getBeanClassLoader())); 
j 
/添加 默认 的 系统 环境 bean 
if 
(!IbeanFactory.containsLocalBean(ENVIRONMENT BEAN NAME)) { 
beanFactory.registerSingleton(ENVIRONMENT BEAN NAME, 
getEnvironment()); 
j 
if 


(!IbeanFactory.containsLocalBean(SYSTEM, PROPERTIES BEAN NAME) 
{ 


beanFactory.registerSingleton(S YSTEM_PROPERTIES_BEAN_NAME, 
getEnvironment(). 
getSystemProperties()); 
} 
if 
(!IbeanFactory.containsLocalBean(SYSTEM ENVIRONMENT BEAN NAM 
{ 


beanFactory.registerSingleton(S YSTEM_ENVIRONMENT_BEAN_NAME, 
getEnvironment(). 


getSystemEnvironment()); 


} 

上 面 函 数 中 主要 进行 了 几 个 方面 的 扩展 。 

增加 对 SPEL 语 言 的 支持 。 

增加 对 属性 编辑 器 的 支持 。 

增加 对 一 些 内 置 类 ， 比 如 EnvironmentAware、MessageSourceAware 
的 信息 注入 。 

设置 了 依赖 功能 可 忽略 的 接口 。 

注册 一 些 固定 依赖 的 属性 。 

增加 Aspect 的 文 持 〈 会 在 第 7 章 中 进行 详细 的 讲解 ) 。 

将 相关 环境 变量 及 属性 注册 以 单 例 模式 注册 。 

可 能 读者 不 是 很 理解 每 个 步骤 的 具体 含义 ， 接 下 来 我 们 会 对 各 个 步 
又 进行 详细 地 分 析 。 





Spring 表达 式 语 言 全 称 为 “Spring Expression Language”， 缩 写 
Jj*SpEL", 2&4 T Struts 2x 中 使 用 的 OGNL 表 达 式 语言 ， 能 在 运行 时 构 
建 复杂 表达 式 、 存 取 对 象 图 属性 、 对 象 方法 调用 等 ， 并 且 能 与 Spring 功 
能 完美 整合 ， 比 如 能 用 来 配置 bean 定 义 。SpEL 是 单独 模块 ， 只 依赖 于 
core 模 块 ， 不 依赖 于 其 他 模块 ， 可 以 单独 使 用 。 

SpEL 使 用 #{...} 作 为 定 界 符 ， 所 有 在 大 框 号 中 的 字符 都 将 被 认为 是 
SPEL， 使 用 格式 如 下 : 


<bean id="saxophone" value-"com.xxx.xxx.Xxx"/» 





<bean > 
<property name="instrument" value="#{saxophone }"/> 

<bean/> 

相当 于 : 

<bean id="saxophone" value="com.xxx.xxx.Xxx"/> 

<bean > 

<property name="instrument" ref="saxophone"/> 

<bean/> 

当然 ， 上 面 只 是 列举 了 其 中 最 简单 的 使 用 方式 ，SPEL 功 能 非常 强 
大 ， 使 用 好 可 以 大 大 提高 开发 效率 ， 这 里 只 为 唤起 读者 的 记忆 来 帮助 我 
们 理解 源码 ， 有 兴趣 的 读者 可 以 进一步 深入 研究 。 

在 源码 中 通过 代码 beanFactory.setBeanExpressionResolver(new 
StandardBeanExpression Resolver()) 注 册 语 言 解析 器 ， 就 可 以 对 SPEL 进 行 
解析 了 ， 那 么 在 注册 解析 器 后 Spring 又 是 在 什么 时 候 调 用 这 个 解析 器 进 
行 解析 呢 ? 

之 前 我 们 讲解 过 Spring 在 bean 进行 初始 化 的 时 候 会 有 属性 填充 的 
一 步 ， 而 在 这 一 步 中 Spring 会 调用 AbstractAutowireCapableBeanFactory 





类 的 applyPropertyValues 函 数 来 完成 功能 。 就 在 这 个 函数 中 ， 会 通过 构 
造 BeanDefinitionValueResolver 类 型 实例 valueResolver 来 进行 属性 值 的 解 
析 。 同 时 ， 也 是 在 这 个 步骤 中 一 般 通 过 AbstractBeanFactory 中 的 
evaluateBeanDefinitionString 方 法 去 完成 SPEL 的 解析 。 


protected Object evaluateBeanDefinitionString(String value, 





BeanDefinition beanDefinition) { 

if (this.beanExpressionResolver == null) { 

return value; 

} 

Scope scope = (beanDefinition != null ? 
getRegisteredScope(beanDefinition.getScope()) : 

null); 

return this.beanExpressionResolver.evaluate(value, new 
BeanExpressionContext(this, 

scope)); 

} 

当 调用 这 个 方法 时 会 判断 是 否 存在 语言 解析 器 ， 如 果 存 在 则 调用 语 
言 解 析 器 的 方法 进行 解析 ， 解 析 的 过 程 是 在 Spring 的 expression 的 包 内 ， 
这 里 不 做 过 多 解释 。 我 们 通过 查看 对 evaluate BeanDefinitionString 方 法 的 
调用 层次 可 以 看 出 ， 应 用 语言 解析 器 的 调用 主要 是 在 解析 依赖 注入 bean 
的 时 候 ， 以 及 在 完成 bean 的 初始 化 和 属性 获取 后 进行 属性 填充 的 时 候 。 








在 Spring DI 注入 的 时 候 可 以 把 普通 属性 注入 进来 ， 但 是 像 Date 类 
就 无 法 被 识别 。 例 如 : 
public class UserManager { 


private Date dataValue; 


public Date getDataValue() { 
return dataValue; 
} 
public void setDataValue(Date dataValue) { 
this.dataValue = dataValue; 
} 
public String toString(){ 


return "dataValue: " + dataValue; 


} 
上 面 代码 中 ， 需 要 对 日 期 型 属性 进行 注入 : 
<bean id="userManager" class="com.test. UserManager"> 
<property name="dataValue"> 
<value>2013-03-15</value> 
</property> 
</bean> 
测试 代码 : 
@Test 
public void testDate()1 
ApplicationContext ctx = new 
ClassPathXmlApplicationContext("beans.xml"); 
UserManager userManager = 
(UserManager)ctx.getBean("userManager"); 
System.out.printIn(userManager); 
} 
如 果 直 接 这 样 使 用 ， 程 序 则 会 报 腊 常 ， 类 型 转换 不 成 功 。 因 为 在 
UserManager 中 的 dataValue 属 性 是 Date 类 型 的 ， 而 在 XML 中 配置 的 却 是 


String 类 型 的 ， 所 以 当然 会 报 异 冲 。 
Spring 针对 此 问题 提供 了 两 种 解雇 办法。 
1. 使 用 自 定 义 属性 编辑 器 
使 用 自 定 义 属性 编辑 器 ， 通 过 继承 PropertyEditorSupport， 重 写 
setAsText 方 法 ， 具 体 步 又 如 下 。 
(1) 编写 目 定 义 的 属性 编辑 器 。 
public class DatePropertyEditor extends PropertyEditorSupport { 








private String format = "yyyy-MM-dd"; 
public void setFormat(String format) { 


this.format = format; 


} 
public void setAsText(String arg0) throws IllegalArgumentException 


System.out.printin("arg0: " + arg0); 
SimpleDateFormat sdf = new SimpleDateFormat(format); 
try 1 
Date d = sdf.parse(arg0); 
this.setValue(d); 
} catch (ParseException e) 1 


e.printStackTrace(); 


} 
(2) 将 目 定 义 属 性 编辑 器 注册 到 Spring 中 。 
<!-- 目 定义 属性 编辑 右 --> 
<bean 
class="org.Springframework.beans.factory.config.CustomEditorConfigurer"> 








<property name="customEditors"> 
<map> 
«entry key="java.util.Date"> 
<bean class="com.test.DatePropertyEditor"> 
<property name-"format" value="yyyy-MM-dd"/> 
</bean> 
</entry> 
</map> 
</property> 
</bean> 
在 配置 文件 中 引入 类 型 为 
org.Springframework.beans.factory.config.CustomEditorConfigurer 的 bean， 
并 在 属性 customEditors 中 加 入 自 定 义 的 属性 编辑 器 ， 其 中 key 为 属性 编 
辑 器 所 对 应 的 类 型 。 通 过 这 样 的 配置 ， 当 Spring 在 注入 bean 的 属性 时 一 
旦 过 到 了 java.util.Date 类 型 的 属性 会 自动 调用 自 定 义 的 
DatePropertyEditor 解析 融 进 行 解析 ， 并 用 解析 结果 代 蔡 配置 属性 进行 注 
入 。 





2. 注册 Spring 自 带 的 属性 编辑 器 CustomDateEditor 
通过 注册 Spring 自 带 的 属性 编辑 器 CustomDateEditor， 具 体 步 又 如 
ee 
(OD FE CR TES SE AE o 
public class DatePropertyEditorRegistrar implements 
Property EditorRegistrar( 
public void registerCustomEditors(PropertyEditorRegistry registry) 1 
registry.registerCustomEditor(Date.class, new 
CustomDateEditor(new SimpleDateFormat 
Cyyyy-MM-dd"),true)); 


} 

(2) 注册 到 Spring 中 。 

<!-- 注 册 Spring 目 带 编 辑 器 --> 

<bean 
class="org.Springframework.beans.factory.config.CustomEditorConfigurer"> 

<property name="propertyEditorRegistrars"> 
<list> 
<bean class="com.test. DatePropertyEditorRegistrar"></bean> 
</list> 
</property> 

</bean> 

通过 在 配置 文件 中 将 自 定义 的 DatePropertyEditorRegistrar 注册 进入 
org.Springframework. beans.factory.config.CustomEditorConfigurer 的 
propertyEditorRegistrars 属 性 中 ， 可 以 具有 与 方法 1 同样 的 效果 。 

我 们 了 解 了 目 定 义 属 性 编辑 器 的 使 用 ， 但 是 ， 似 乎 这 与 本 节 中 国 经 
的 核心 代码 beanFactory.add PropertyEditorRegistrar(new 
ResourceEditorRegistrar(this, getEnvironment())) 并 无 联系 ， 因 为 在 注册 自 
定义 属性 编辑 器 的 时 候 使 用 的 是 PropertyEditorRegistry 的 
registerCustomEditor 方 法 ， 而 这 里 使 用 的 是 
ConfigurableListableBeanFactory 的 addPropertyEditorRegistrar 方 法 。 我 们 
不 妨 深入 探索 一 下 ResourceEditorRegistrar 的 内 部 实现 ， 在 
ResourceEditorRegistrar 中 ， 我 们 最 关心 的 方法 是 registerCustomEditors 。 

public void registerCustomEditors(PropertyEditorRegistry registry) { 

















ResourceEditor baseEditor = new 
ResourceEditor(this.resourceLoader, this. 


property Resolver); 


doRegisterEditor(registry, Resource.class, baseEditor); 
doRegisterEditor(registry, ContextResource.class, baseEditor); 
doRegisterEditor(registry, InputStream.class, new 
InputStreamEditor(baseEditor)); 
doRegisterEditor(registry, InputSource.class, new 
InputSourceEditor(baseEditor)); 
doRegisterEditor(registry, File.class, new FileEditor(baseEditor)); 
doRegisterEditor(registry, URL.class, new URLEditor(baseEditor)); 
ClassLoader classLoader = this.resourceLoader.getClassLoader(); 
doRegisterEditor(registry, URI.class, new URIEditor(classLoader)); 
doRegisterEditor(registry, Class.class, new 
ClassEditor(classLoader)); 
doRegisterEditor(registry, Class[].class, new 
ClassArrayEditor(classLoader)); 
if (this.resourceLoader instanceof ResourcePatternResolver) 1 
doRegisterEditor(registry, Resource[ ].class, 
new ResourceArrayPropertyEditor((ResourcePatternResolver) 
this. 


resourceLoader, this.propertyResolver)); 


private void doRegisterEditor(PropertyEditorRegistry registry, Class<?> 
requiredType, 
Property Editor editor) { 
if (registry instanceof PropertyEditorRegistrySupport) 1 
((PropertyEditorRegistrySupport) registry).overrideDefaultEditor 
(requiredType, 


editor); 
} 
else { 


registry.registerCustomEditor(requiredType, editor); 


} 

在 doRegisterEditor 函数 中 ， 可 以 看 到 在 之 前 提 到 的 自 定 义 属性 中 
使 用 的 关键 代码 : registry.registerCustomEditor(requiredType, editor), [P] 
过 头 来 看 ResourceEditorRegistrar 类 的 registerCustomEditors 方 法 的 核心 
功能 ， 其 实 无 非 是 注册 了 一 系列 的 常用 类 型 的 属性 编辑 器 ， 例 如 ， 代 三 
doRegisterEditor(registry, Class.class, new ClassEditor(classLoader)) 9:3 ff] 
功能 就 是 注册 Class 类 对 应 的 属性 编辑 器 。 那 么 ， 注 册 后 ， 一 旦 某 个 实体 
bean 中 存在 一 些 Class 类 型 的 属性 ， 那 么 Spring 会 调用 ClassEditor 将 配置 
中 定义 的 String 类 型 转换 为 Class 类 型 并 进行 赋值 。 

分 析 到 这 里 ， 我 们 不 禁 有 个 疑问 ， 虽 说 ResourceEditorRegistrar 类 的 
registerCustomEditors 方 法 实现 了 批量 注册 的 功能 ， 但 是 
beanFactory.addPropertyEditorRegistrar(new ResourceEditorRegistrar(this, 
getEnvironmentO)) 仅 仅 是 注册 了 ResourceEditorRegistrar 实 例 ， 却 并 没有 
调用 ResourceEditorRegistrar 的 registerCustomEditors 方法 进行 注册 ， 那 
么 到 底 是 在 什么 时 候 进 行 注 册 的 昵 ? 进一步 查看 ResourceEditorRegistrar 
的 registerCustomEditors 方 法 的 调用 层次 结构 ， 如 图 6-1 所 示 。 





© registerCustomEditors(PropertyEditorRegistry) : void - org.springframewe t.Re ditorR r 
registerCustomEditors(PropertyEditorRegistry) : void - org. cc E E E S 


图 6-1 ResourceEditorRegistrar 的 registerCustomEditors 方 法 的 调用 层次 结 
构 


发 现在 AbstractBeanFactory 中 的 registerCustomEditors 方法 中 被 调 


用 过 ， 继 续 得 看 AbstractBeanFactory 中 的 registerCustomEditors 方 法 的 调 
用 层次 结构 ， 如 图 6-2 所 示 。 


4 registerCustomEditors(PropertyEditorRegistry) : void - org.springframework bass latory sure Ansiractbaenfachon. 
o li uic ee V qi. iil iili id org.springframework.beans.factory.support.AbstractB eanFactory 
© getTypeConverter() : TypeConverter - org.springframework.beans.factory.support.AbstractB eanFactory 
initBeanWrapper(BeanWrapper) : void - org.springframework.beans.factory.support.AbstractB eanFactory 


图 6-2 AbstractBeanFactory 中 的 registerCustomEditors 方 法 的 调用 层次 结 
构 


其 中 我 们 看 到 Nd s 悉 的 ， 就 是 AbstractBeanFactory 类 
中 的 initBeanWrapper 方 法 ， 这 是 在 bean 初始 化 时 使 用 的 一 个 方法 ， 之 
前 已 经 使 用 过 大 量 的 篇 幅 进行 讲解 ， 主 要 是 在 将 BeanDefinition 转 换 为 
BeanWrapper 后 用 于 对 属性 的 填充 。 到 此 ， 逻 辑 已 经 明了 ， 在 bean 的 初 
始 化 后 会 调用 ResourceEditorRegistrar 的 registerCustomEditors 方 法 进行 批 
量 的 通用 属性 编辑 器 注册 。 注 册 后 ， 在 属性 填充 的 环节 便 可 以 直接 让 
Spring 使 用 这 些 编 辑 器 进行 属性 的 解析 了 。 
既然 提 到 了 BeanWrapper， 这 里 也 有 必要 强调 下 ，Spring 中 用 于 封 
装 bean 的 是 BeanWrapper 类 型 ， 而 它 又 间接 继承 了 PropertyEditorRegistry 
类 型 ， 也 就 是 我 们 之 前 反复 看 到 的 方法 参数 PropertyEditorRegistry 
registry， 其 实 大 部 分 情况 下 都 是 BeanWrapper， 对 于 BeanWrapper 在 
Spring 中 的 默认 实现 是 BeanWrapperImpl， 而 BeanWrapperImpl 除 了 实现 
BeanWrapper 接 口外 还 继承 了 PropertyEditorRegistrySupport， 在 
PropertyEditorRegistrySupport 中 有 这 样 一 个 方法 : 
private void createDefaultEditors() { 
this.defaultEditors = new HashMap<Class<?>, PropertyEditor>(64); 
// Simple editors, without parameterization capabilities. 


// The JDK does not contain a default editor for any of these target 


types. 


this.defaultEditors.put(Charset.class, new CharsetEditor()); 

this.defaultEditors.put(Class.class, new ClassEditor()); 

this.defaultEditors.put(Class[].class, new ClassArrayEditor()); 

this.defaultEditors.put(Currency.class, new CurrencyEditor()); 

this.defaultEditors.put(File.class, new FileEditor()); 

this.defaultEditors.put(InputStream.class, new InputStreamEditor()); 

this.defaultEditors.put(InputSource.class, new InputSourceEditor()); 

this.defaultEditors.put(Locale.class, new LocaleEditor()); 

this.defaultEditors.put(Pattern.class, new PatternEditor()); 

this.defaultEditors.put(Properties.class, new PropertiesEditor()); 

this.defaultEditors.put(Resource[].class, new 
Resource Array PropertyEditor()); 

this.defaultEditors.put(TimeZone.class, new TimeZoneEditor()); 

this.defaultEditors.put(URI.class, new URIEditor()); 

this.defaultEditors.put(URL.class, new URLEditor()); 

this.defaultEditors.put(UUID.class, new UUIDEditor()); 

// Default instances of collection editors. 

// Can be overridden by registering custom instances of those as 
custom editors. 

class)); 

this.defaultEditors.put(Collection.class, new CustomCollectionEditor 
(Collection. 

this.defaultEditors.put(Set.class, new 
CustomCollectionEditor(Set.class)); 

class)); 

this.defaultEditors.put(SortedSet.class, new CustomCollectionEditor 
(SortedSet. 


this.defaultEditors.put(List.class, new 
CustomCollectionEditor(List.class)); 

this.defaultEditors.put(SortedMap.class, new 
CustomMapEditor(SortedMap.class)); 

// Default editors for primitive arrays. 

this.defaultEditors.put(byte[].class, new ByteArrayPropertyEditor()); 

this.defaultEditors.put(char[].class, new CharArrayPropertyEditor()); 

// The JDK does not contain a default editor for char! 

this.defaultEditors.put(char.class, new CharacterEditor(false)); 

this.defaultEditors.put(Character.class, new CharacterEditor(true)); 

// Spring's CustomBooleanEditor accepts more flag values than the 
JDK's default editor. 

this.defaultEditors.put(boolean.class, new 
CustomBooleanEditor(false)); 

this.defaultEditors.put(Boolean.class, new 
CustomBooleanEditor(true)); 

// The JDK does not contain default editors for number wrapper 
types! 

// Override JDK primitive number editors with our own 
CustomNumberEditor. 

this.defaultEditors.put(byte.class, new 
CustomNumberEditor(Byte.class, false)); 

this.defaultEditors.put(Byte.class, new 
CustomNumberEditor(Byte.class, true)); 

this.defaultEditors.put(short.class, new 
CustomNumberEditor(Short.class, false)); 

this.defaultEditors.put(Short.class, new 


CustomNumberEditor(Short.class, true)); 
this.defaultEditors.put(int.class, new 
CustomNumberEditor(Integer.class, false)); 
this.defaultEditors.put(Integer.class, new 
CustomNumberEditor(Integer.class, true)); 
this.defaultEditors.put(long.class, new 
CustomNumberEditor(Long.class, false)); 
this.defaultEditors.put(Long.class, new 
CustomNumberEditor(Long.class, true)); 
this.defaultEditors.put(float.class, new 
CustomNumberEditor(Float.class, false)); 
this.defaultEditors.put(Float.class, new 
CustomNumberEditor(Float.class, true)); 
this.defaultEditors.put(double.class, new 
CustomNumberEditor(Double.class, false)); 
this.defaultEditors.put(Double.class, new 
CustomNumberEditor(Double.class, true)); 
this.defaultEditors.put(BigDecimal.class, new 
CustomNumberEditor(BigDecimal. 
class, true)); 
this.defaultEditors.put(BigInteger.class, new 
CustomNumberEditor(BigInteger. 
class, true)); 
// Only register config value editors if explicitly requested. 
if (this.config ValueEditorsActive) { 
StringArrayPropertyEditor sae = new StringArrayPropertyEditor(); 
this.defaultEditors.put(String[].class, sae); 


this.defaultEditors.put(short[].class, sae); 
this.defaultEditors.put(int[].class, sae); 
this.defaultEditors.put(long[].class, sae); 


} 

其 体 的 调用 方法 我 们 就 不 去 深究 了 ， 但 是 至 少 通 过 这 个 方法 我 们 已 
经 知道 了 在 Spring 中 定义 了 上 面 一 系列 常用 的 属性 编辑 器 使 我 们 可 以 方 
便 地 进行 配置 。 如 果 我 们 定义 的 bean 中 的 某 个 属性 的 类 型 不 在 上 面 的 
常用 配置 中 的 话 ， 才 需要 我 们 进行 个 性 化 属性 编辑 器 的 注册 。 





了 解 了 属性 编辑 器 的 使 用 后 ， 接 下 来 我 们 继续 通过 
AbstractApplicationContext 的 prepareBeanFactory 方法 的 主线 来 进行 函数 
跟踪 。 对 于 beanFactory.addBeanPostProcessor(new 
ApplicationContextAwareProcessor(this)) 其 实 主 要 目的 就 是 注册 个 
BneaPostProcessor， 而 真正 的 逻辑 还 是 在 


ApplicationContextAwareProcessor 中 。 


ApplicationContextAwareProcessor 实 现 BeanPostProcessor 接 口 ， 我 们 
回顾 下 之 前 讲 过 的 内 容 ， 在 bean 实 例 化 的 时 候 ， 也 就 是 Spring 激活 bean 
的 init-method 的 前 后 ， 会 调用 BeanPost Processor 的 
postProcessBeforeInitialization 方 法 和 postProcessAfterInitialization 方 法 。 
同样 ， 对 于 ApplicationContextAwareProcessor 我 们 也 关心 这 两 个 方法 。 

对 于 postProcessAfterInitialization 方 法 ， 在 
ApplicationContextAwareProcessor 中 并 没有 做 过 多 逻辑 处 理 。 

public Object postProcessA fterInitialization(Object bean, String 





beanName) { 


return bean; 


} 
那么 ， 我 们 重点 看 一 下 postProcessBeforeInitialization 方 法 。 
public Object postProcessBeforelnitialization(final Object bean, String 
beanName) throws 
BeansException { 
AccessControlContext acc = null; 
if (System.getSecurityManager() != null && 
(bean instanceof EnvironmentA ware || bean instanceof 
EmbeddedValue 
ResolverAware || 
bean instanceof ResourceLoaderA ware || bean instanceof 
ApplicationEventPublisherA ware || 
bean instanceof MessageSourceA ware || bean instanceof 
ApplicationContextA ware)) { 
acc = 
this.applicationContext.getBeanFactory().getAccessControlContext(); 
} 
if (acc != null) { 
AccessController.doPrivileged(new PrivilegedAction<Object>() { 
public Object run() { 
invokeA wareInterfaces(bean); 
return null; 
j 
}, acc); 
} 
else { 


invokeA wareInterfaces(bean); 


} 
return bean; 
} 
private void invokeA wareInterfaces(Object bean) { 
if (bean instanceof Aware) { 
if (bean instanceof EnvironmentAware) { 
((EnvironmentA ware) 
bean).setEnvironment(this.applicationContext. 
getEnvironment()); 
} 
if (bean instanceof EmbeddedValueResolverAware) { 
((EmbeddedV alueResolverA ware) 
bean).setEmbeddedV alueResolver( 
new Embedded ValueResolver(this.applicationContext. getBean 
Factory())); 
j 
if (bean instanceof ResourceLoaderA ware) { 
((ResourceLoaderA ware) 
bean).setResourceLoader(this.applicationContext); 
} 
if (bean instanceof ApplicationEventPublisherAware) { 
((ApplicationEventPublisherA ware) 
bean).setApplicationEventPublisher 
(this.applicationContext); 
} 
if (bean instanceof MessageSourceAware) { 


((MessageSourceA ware) 


bean).setMessageSource(this.applicationContext); 
} 
if (bean instanceof ApplicationContextAware) { 
((ApplicationContextA ware) bean).setApplicationContext(this. 


applicationContext); 


} 

postProcessBeforelnitialization 方法 中 调用 了 
invokeAwareInterfaces。 从 invokeAwareInterfaces 方 法 中 ， 我 们 或 许 已 经 
或 多 或 少 了 解 了 Spring 的 用 意 ， 实 现 这 些 Aware 接 口 的 bean 在 被 初始 化 
之 后 ， 可 以 取得 一 些 对 应 的 资源 。 


6.5.4 ix ELA f 


当 Spring 将 ApplicationContextAwareProcessor 注 册 后 ， 那 么 在 
invokeAwareInterfaces 方 法 中 间接 调用 的 Aware 类 已 经 不 是 普通 的 bean 
了 ， 如 ResourceLoaderAware、ApplicationEventPublisher Aware 等 ， 那 
么 当然 需要 在 Spring 做 bean 的 依赖 注入 的 时 候 忽略 它们 。 而 
ignoreDependencyInterface 的 作用 正 是 在 此 。 

/设置 了 几 个 忽略 目 动 装配 的 接口 





beanFactory.ignoreDependencyInterface(ResourceLoaderAware.class); 


beanFactory.ignoreDependencyInterface(A pplicationEventPublisherA ware.cli 


beanFactory.ignoreDependencyInterface(MessageSourceA ware.class); 


beanFactory.ignoreDependencyInterface(ApplicationContextAware.class); 


beanFactory.ignoreDependencyInterface(EnvironmentAware.class); 
6.5.5 注 ji 
Spring 中 有 了 忽略 依赖 的 功能 ， 当 然 也 必 不 可 少 地 会 有 注册 依赖 的 


beanFactory.registerResolvableDependency(BeanFactory.class, 
beanFactory); 
beanFactory.registerResolvableDependency(ResourceLoader.class, 
this); 


beanFactory.registerResolvableDependency(ApplicationEventPublisher.class, 
this); 


beanFactory.registerResolvableDependency(ApplicationContext.class, this); 

当 注 册 了 依赖 解析 后 ， 例 如 当 注 册 了 对 BeanFactory.class 的 解析 依 
赖 后 ， 当 bean 的 属性 注入 的 时 候 ， 一 旦 检测 到 属性 为 BeanFactory 类 型 便 
会 将 beanFactory 的 实例 注入 进去 。 


6.6 BeanFactory{{ HI 


BeanFacotry 作 为 Spring 中 容 吉 功能 的 基础 ， 用 于 存放 所 有 已 经 加 载 
的 bean， 为 了 保证 程序 上 的 高 可 扩展 性 ，Spring 针对 BeanFactory 做 了 
大 量 的 扩展 ， 比 如 我 们 熟知 的 PostProcessor 等 都 是 在 这 里 实现 的 。 





正式 开始 介绍 之 前 我 们 先 了 解 下 BeanFactoryPostProcessor 的 用 法 。 
BeanFactoryPostProcessor 接 口 跟 BeanPostProcessor 类 似 ， 可 以 对 


bean 的 定义 《配置 元 数据 〉 进 行 处 理 。 也 就 是 说 ，Spring loC# 4s YF 
BeanFactoryPostProcessor 在 容器 实际 实例 化 任何 其 他 的 bean 之 前 读 取 配 
置 元 数据 ， 并 有 可 能 修改 它 。 如 果 你 愿意 ， 你 可 以 配置 多 个 
BeanFactoryPostProcessor。 你 还 能 通过 设置 “order” 属 性 来 控制 
BeanFactoryPostProcessor 的 执行 次 序 〈 仅 当 BeanFactoryPostProcessor 实 
现 了 Ordered 接口 时 你 才 可 以 设置 此 属性 ， 因 此 在 实现 
BeanFactoryPostProcessor 时 ， 就 应 当 考 虑 实现 Ordered 接口 ) 。 请 参考 


BeanFactoryPostProcessor 和 Ordered 接 口 的 JavaDoc 以 获取 更 详细 的 信 
S 
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如 有 果 你 想 改 变 实际 的 bean. 实例 (例如 从 配置 元 数据 创建 的 对 
$0 ， 那 么 你 最 好 使 用 BeanPostProcessor。 同 样 地 ， 
BeanFactoryPostProcessor 的 作用 域 范 围 是 容器 级 的 。 它 只 和 你 所 使 用 的 
Bas AK. WRITER APEXA BeanFactoryPostProcessor, “(1M 
MULAN beanwt 47 Ja E Mb. BeanFactoryPostProcessor/4^ 42 Xt 4E X. 
在 另 一 个 容器 中 的 bean 进 行 后 置 处 理 ， 即 使 这 两 个 容器 都 是 在 同一 层次 
上 。 在 Spring 中 存在 对 于 BeanFactoryPostProcessor 的 典型 应 用 ， 比 如 
PropertyPlaceholderConfigurer。 

1. BeanFactoryPostProcessor 的 典型 应 用 : 
PropertyPlaceholderConfigurer 

有 时 候 ， 疯 读 Spring 的 Bean 描 述 文件 时 ， 你 也 许 会 遇 到 类 似 如 下 的 
— ES AC EI: 


<bean id-" message" class="distConfig. HelloMessage"> 





<property name="mes"> 
<value>${bean.message }</value> 
</property> 
</bean> 
其 中 竟然 出 现 了 变量 引用 : ${bean.message}。 这 就 是 Spring 的 分 散 


配置 ， 可 以 在 另外 的 配置 文件 中 为 bean.message 指 定 值 。 如 在 
bean.property 配 置 如 下 定义 : 

bean.message=Hi,can you find me? 

当 访 问 名 为 message 的 bean 时 ，mes 属 性 就 会 被 置 为 字符 串 “ Hi,can 
you find me?”， 但 Spring 框架 是 怎么 知道 存在 这 样 的 配置 文件 呢 ? 这 就 
要 靠 PropertyPlaceholderConfigurer 这 个 类 的 bean: 





<bean id="mesHandler" 
class="org.Springframework.beans.factory.config. Property Placeholder 
Configurer"> 
<property name="locations"> 
<list> 
<value>config/bean.properties</value> 
</list> 
</property> 
</bean> 
在 这 个 bean 中 指定 了 配置 文件 为 config/bean.properties。 到 这 里 似乎 
找到 问题 的 答案 了 ， 但 是 其 实 还 有 个 问题 。 这 个 “mesHandler” 只 不 过 是 
Spring 框架 管理 的 一 个 bean， 并 没有 被 别 的 bean 或 者 对 象 引 用 ，Spring 的 
beanFactory 是 怎么 知道 要 从 这 个 bean 中 获取 配置 信息 的 呢 ? 
查看 层级 结构 可 以 看 出 PropertyPlaceholderConfigurer 这 个 类 间接 继 
7K f BeanFactory PostProcessor 接 口 。 这 是 一 个 很 特别 的 接口 ， 当 Spring 
加 载 任何 实现 了 这 个 接口 的 bean 的 配置 时 ， 都 会 在 bean 工厂 载 入 所 有 
bean 的 配置 之 后 执行 postProcessBeanFactory 方法 。 在 
PropertyResourceConfigurer 类 中 实现 了 postProcessBeanFactory 方法 ， 在 





方法 中 先后 调用 了 mergeProperties、convertProperties、ProcessProperties 
这 3 个 方法 ， 分 别 得 到 配置 ， 将 得 到 的 配置 转换 为 合适 的 类 型 ， 最 后 将 
配置 内 容 告知 BeanFactory。 


正 是 通过 实现 BeanFactoryPostProcessor 接 口 ，BeanFactory 会 在 实例 
化 任何 bean 之 前 获得 配置 信息 ， 从 而 能 够 正确 解析 bean 描 述 文件 中 的 变 
量 引 用 。 
2. 使 用 目 定 义 BeanFactoryPostProcessor 
我 们 以 实现 一 个 BeanFactoryPostProcessor， 云 除 潜 在 的 “流氓 ”属性 
值 的 功能 来 展示 自 定 义 BeanFactoryPostProcessor 的 创建 及 使 用 ， 例 如 
bean 定 义 中 留 下 bollocks 这 样 的 字眼 。 
配置 文件 BeanFactory.xml 
<?xml version="1.0" encoding="UTF-8"?> 
«beans xmlns="http://www.Springframework.org/schema/beans" 
xmins:xsi-"http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www.Springframework.org/schema/beans/Spring-beans.xsd 
"s 
<bean id-"bfpp" 
class="com.Spring.ch04.ObscenityRemovingBeanFactoryPostProcessor"> 
<property name="obscenties"> 
<set> 
<value>bollocks</value> 
<value>winky</value> 
<value>bum</value> 
<value>Microsoft</value> 
</set> 
</property> 
</bean> 
<bean id="simpleBean" 


class="com.Spring.ch04.SimplePostProcessor"> 


<property name-"connectionString" value="bollocks"/> 
<property name="password" value="imaginecup"/> 
<property name-"username" value="Microsoft"/> 
</bean> 
</beans> 
ObscenityRemovingBeanFactoryPostProcessor.java 
public class ObscenityRemovingBeanFactoryPostProcessor implements 
BeanFactoryPostProcessor { 
private Set<String> obscenties; 
public Obscenity RemovingBeanFactoryPostProcessor(){ 
this.obscenties=new HashSet<String>(); 
} 
public void postProcessBeanFactory( 
ConfigurableListableBeanFactory beanFactory) throws 
BeansException { 
String[] beanNames=beanFactory.getBeanDefinitionNames(); 
for(String beanName:beanNames){ 
BeanDefinition bd=beanFactory.getBeanDefinition(beanName); 


String ValueResolver valueResover=new String ValueResolver() 


public String resolveStringValue(String strVal) { 
if(isObscene(strVal)) return "*****"; 
return str Val; 
j 
}; 
BeanDefinitionVisitor visitor=new 


BeanDefinition Visitor(valueResover); 


visitor.visitBeanDefinition(bd); 


} 

public boolean isObscene(Object value){ 
String potentialObscenity=value.toString().to UpperCase(); 
return this.obscenties.contains(potentialObscenity); 

} 

public void setObscenties(Set<String> obscenties) { 
this.obscenties.clear(); 
for(String obscenity:obscenties) { 


this.obscenties.add(obscenity.toUpperCase()); 


} 
执行 类 : 
public class PropertyConfigurerDemo { 
public static void main(String[] args) { 
ConfigurableListableBeanFactory bf=new XmlBeanFactory(new 
ClassPathResource 
("/META-INF/BeanFactory.xml")); 
BeanFactoryPostProcessor bfpp= 
(BeanFactoryPostProcessor)bf.getBean("bfpp"); 
bfpp.postProcessBeanFactory(bf); 
System.out.println(bf.getBean("simpleBean")); 


) 
输出 结果 : 


SimplePostProcessor{connectionString=*****, username=***** passwo 
ii ObscenityRemovingBeanFactoryPostProcessor Spring 很 好 地 实现 
了 屏蔽 掉 obscenties 定 义 的 不 应 该 展示 的 属性 。 
3. 激活 BeanFactoryPostProcessor 
了 解 了 BeanFactoryPostProcessor 的 用 法 后 便 可 以 深入 研究 
BeanFactoryPostProcessor 的 调用 过 程 了 。 
protected void 
invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory 
beanFactory) { 
// Invoke BeanDefinitionRegistryPostProcessors first, if any. 
Set<String> processedBeans = new HashSet<String>(); 
// 对 BeanDefinitionRegistry 类 型 的 处 理 
if (beanFactory instanceof BeanDefinitionRegistry) { 
BeanDefinitionRegistry registry = (BeanDefinitionRegistry) 
beanFactory; 
List<BeanFactoryPostProcessor> regularPostProcessors = new 
LinkedList<BeanFactoryPostProcessor>(); 
pee 
* BeanDefinitionRegistryPostProcessor 
n 
List<BeanDefinitionRegistryPostProcessor> 
registryPostProcessors = 
new&nbsp;LinkedList<BeanDefinitionRegistryPostProcessor>(); 
f* 
* 便 编码 注册 的 后 处 理 器 
"2 


for (BeanFactoryPostProcessor postProcessor : 


getBeanFactoryPostProcessors()) { 
if (postProcessor instanceof 
BeanDefinitionRegistryPostProcessor) { 
BeanDefinitionRegistryPostProcessor registryPostProcessor = 
(Bean DefinitionRegistryPostProcessor) postProcessor; 
/对 于 BeanDefinitionRegistryPostProcessor 类 型 ， 在 
BeanFactoryPostProcessor 的 基础 上 还 有 自己 定义 的 方法 ， 需 要 先 调 用 


registryPostProcessor.postProcessBeanDefinitionRegistry(registry); 
registryPostProcessors.add(registryPostProcessor); 
}else { 
/记录 常规 BeanFactoryPostProcessor 


regularPostProcessors.add(postProcessor); 


* BC EM A Je RE as 
2 
Map<String, BeanDefinitionRegistryPostProcessor> beanMap = 
beanFactory. 
getBeansOfType(BeanDefinitionRegistryPostProcessor.class, true, 
false); 
List<BeanDefinitionRegistryPostProcessor> 
registryPostProcessorBeans = 
new ArrayList<BeanDefinitionRegistryPostProcessor> 
(beanMap.values()); 


OrderComparator.sort(registry PostProcessorBeans); 


for (BeanDefinitionRegistryPostProcessor postProcessor : 
registryPostProcessorBeans) { 
/BeanDefinitionRegistryPostProcessor 的 特殊 处 理 
postProcessor.postProcessBeanDefinitionRegistry(registry); 
} 
/激活 postProcessBeanFactory 方 法 ， 之 前 激活 的 是 
postProcessBeanDefinitionRegistry 
// 硬 编码 设置 的 BeanDefinitionRegistryPostProcessor 
invokeBeanFactoryPostProcessors(registryPostProcessors, 
beanFactory); 
/配置 的 BeanDefinitionRegistryPostProcessor 
invokeBeanFactoryPostProcessors(registryPostProcessorBeans, 
beanFactory); 
// 常 规 BeanFactoryPostProcessor 
invokeBeanFactoryPostProcessors(regularPostProcessors, 
beanFactory); 
processedBeans.addAll(beanMap.keySet()); 
} 
else { 


// Invoke factory processors registered with the context instance. 


invokeBeanFactoryPostProcessors(getBeanFactoryPostProcessors(), 
beanFactory); 
} 
/对 于 配置 中 读 取 的 BeanFactoryPostProcessor 的 处 理 
String[] postProcessorNames = 


beanFactory.getBeanNamesForType(BeanFactoryPost 


Processor.class, true, false); 
List<BeanFactoryPostProcessor> priorityOrderedPostProcessors = 
new ArrayList 
<BeanFactoryPostProcessor>(); 
List<String> orderedPostProcessorNames = new ArrayList<String> 
0; 
List<String> nonOrderedPostProcessorNames = new 
ArrayList<String>(); 
/对 后 处 理 器 进行 分 类 
for (String ppName : postProcessorNames) { 
if (processedBeans.contains(ppName)) { 
/已 经 处 理 过 
}else if (isTypeMatch(ppName, PriorityOrdered.class)) { 


priorityOrderedPostProcessors.add(beanFactory.getBean(ppName, 
BeanFactoryPostProcessor.class)); 
}else if (isTypeMatch(ppName, Ordered.class)) { 
orderedPostProcessorNames.add(ppName); 
}else { 
nonOrderedPostProcessorNames.add(ppName); 


} 

/按照 优先 级 进行 排序 
OrderComparator.sort(priorityOrderedPostProcessors); 
invokeBeanFactoryPostProcessors(priorityOrderedPostProcessors, 


beanFactory); 
// Next, invoke the BeanFactoryPostProcessors that implement 


Ordered. 
List<BeanFactoryPostProcessor> orderedPostProcessors = new 
ArrayList<BeanFactory 
PostProcessor>(); 
for (String postProcessorName : orderedPostProcessorNames) { 
orderedPostProcessors.add(getBean(postProcessorName, 
BeanFactoryPostProcessor. 
class)); 
} 
/按照 order 排 序 
OrderComparator.sort(orderedPostProcessors); 
invokeBeanFactoryPostProcessors(orderedPostProcessors, 
beanFactory); 
/无 序 ， 直 接 调 用 
List<BeanFactoryPostProcessor> nonOrderedPostProcessors = new 
ArrayList<BeanFactory 
PostProcessor>(); 
for (String postProcessorName : nonOrderedPostProcessorNames) { 
nonOrderedPostProcessors.add(getBean(postProcessorName, 
BeanFactoryPostProcessor.class)); 
} 
invokeBeanFactoryPostProcessors(nonOrderedPostProcessors, 
beanFactory); 


} 

从 上 面 的 方法 中 我 们 看 到 ， 对 于 BeanFactoryPostProcessor 的 处 理 
主要 分 两 种 情况 进行 ， 一 个 是 对 于 BeanDefinitionRegistry 类 的 特殊 处 
理 ， 另 一 种 是 对 普通 的 BeanFactoryPostProcessor 进 行 处 理 。 而 对 于 每 种 


情况 都 需要 考虑 便 编 码 注 入 注册 的 后 处 理 器 以 及 通过 配置 注入 的 后 处 理 
f o 
对 于 BeanDefinitionRegistry 类 型 的 处 理 类 的 处 理 主 要 包括 以 下 内 


OD 对 于 硬 编码 注册 的 后 处 理 器 的 处 理 ， 主 要 是 通过 
AbstractApplicationContext 中 的 添加 处 理 器 方法 
addBeanFactoryPostProcessor 进 行 添 加 。 

public void addBeanFactoryPostProcessor(BeanFactoryPostProcessor 
beanFactoryPostProcessor) { 
this.beanFactoryPostProcessors.add(beanFactoryPostProcessor); 
} 
添加 后 的 后 处 理 器 会 存放 在 beanFactoryPostProcessors 中 ， 而 在 处 理 
BeanFactoryPostProcessor 时 候 会 首先 检测 beanFactoryPostProcessors 是 否 
有 数据 。 当 然 ，BeanDefinitionRegistryPostProcessor 继 承 目 
BeanFactoryPostProcessor， 不 但 有 BeanFactoryPostProcessor 的 特性 ， 同 
时 还 有 自己 定义 的 个 性 化 方法 ， 也 需要 在 此 调用 。 上 所以， 这 里 需要 从 
beanFactoryPostProcessors 中 挑 出 BeanDefinitionRegistryPostProcessor 的 
后 处 理 器 ， 并 进行 其 postProcessBeanDefinitionRegistry 方 法 的 激活 。 
(2) 记录 后 处 理 器 主要 使 用 了 三 个 List 完 成 。 
registryPostProcessors: 记录 通过 硬 编 码 方式 注册 的 
BeanDefinitionRegistryPostProcessorZ$ 1? HY) Ab 38 2$ 0 
regularPostProcessors: 记录 通过 便 编 码 方式 注册 的 
BeanFactoryPostProcessor 类 型 的 处 理 器 。 
registryPostProcessorBeans: 记录 通过 配置 方式 注册 的 
BeanDefinitionRegistryPostProcessorZ$ 1? [^] Ab 38 2$ 0 
(3) 对 以 上 所 记录 的 List 中 的 后 处 理 器 进行 统一 调用 


BeanFactoryPostProcessor 的 postProcessBeanFactory 方 法 。 


(4) 对 beanFactoryPostProcessors 中 非 
BeanDefinitionRegistryPostProcessor 类 型 的 后 处 理 器 进行 统一 的 
BeanFactoryPostProcessor 的 postProcessBeanFactory 方 法 调用 。 

(5) 普通 beanFactory 处 理 。 

BeanDefinitionRegistryPostProcessor 只 对 BeanDefinitionRegistry 类 型 
的 ConfigurableListable BeanFactory 有 效 ， 所 以 如 果 判 断 所 示 的 
beanFactory 并 不 是 BeanDefinitionRegistry， 那 么 便 可 以 忽略 
BeanDefinitionRegistryPostProcessor， 而 直接 处 理 
BeanFactoryPostProcessor， 当 然 获 取 的 方式 与 上 面 的 获取 类 似 。 

这 里 需要 提 到 的 是 ， 对 于 便 编 码 方式 手动 添加 的 后 处 理 器 是 不 需要 
做 任何 排序 的 ， 但 是 在 配置 文件 中 读 取 的 处 理 器 ，Sping 并 不 保证 读 取 
的 顺序 。 所 以 ， 为 了 保证 用 户 的 调用 顺序 的 要 求 ，Spring 对 于 后 处 理 器 
的 调用 支持 按照 PriorityOrdered 或 者 Ordered 的 顺序 调用 。 


6.6.2 注册 BeanPostProcessor 


上 文中 提 到 了 BeanFacotoryPostProcessors 的 调用 ， 现 在 我 们 来 探索 
下 BeanPostProcessor， 但 是 这 里 并 不 是 调用 ， 而 是 注册 。 真 正 的 调用 其 
实 是 在 bean 的 实例 化 阶段 进行 的 。 这 是 一 个 很 重要 的 步骤 ， 也 是 很 多 
功能 BeanFactory 不 支持 的 重要 原因 。Spring 中 大 部 分 功能 都 是 通过 后 处 
理 器 的 方式 进行 扩展 的 ， 这 是 Spring 框架 的 一 个 特性 ， 但 是 在 
BeanFactory 中 其 实 并 没有 实现 后 处 理 器 的 自动 注册 ， 所 以 在 调用 的 时 候 
如 果 没 有 进行 手动 注册 其 实 是 不 能 使 用 的 。 但 是 在 ApplicationContext 中 
却 添加 了 自动 注册 功能 ， 如 自 定义 这 样 一 个 后 处 理 器 : 


public class MyInstantiationA wareBeanPostProcessor implements 














InstantiationA wareBean 
PostProcessor{ 


public Object postProcessBeforelnitialization(Object bean, String 


beanName) 
throws BeansException { 
System.out.printIn("===="); 


return null; 


eee ooo 


在 配置 文件 中 添加 配置 : 
<bean class="processors.MyInstantiationAwareBeanPostProcessor"/> 
那么 使 用 BeanFactory 方式 进行 Spring 的 bean 的 加 载 时 是 不 会 有 任 
何 改 变 的 ， 但 是 使 用 ApplicationContext 方 式 获 取 bean 的 时 候 会 在 获取 每 
个 bean 时 打印 出 “====”， 而 这 个 特性 束 是 在 registerBeanPostProcessors 方 
法 中 完成 的 。 
我 们 继续 探索 registerBeanPostProcessors 的 方法 实现 。 
protected void 
registerBeanPostProcessors(ConfigurableListableBeanFactory beanFactory) 
{ 
String[] postProcessorNames = 
beanFactory.getBeanNamesForType(BeanPostProcessor.class, 
true, false); 
f* 
* BeanPostProcessorChecker 是 一 个 普通 的 信息 打印 ， 可 能 会 有 


* 当 Spring 的 配置 中 的 后 处 理 器 还 没有 被 注册 惑 已 经 开始 了 
bean 的 初始 化 时 

* 便 会 打印 出 BeanPostProcessorChecker 中 设 定 的 信息 

1 


int beanProcessorTargetCount = 
beanFactory.getBeanPostProcessorCount() + 1 + 
postProcessorNames.length; 
beanFactory.addBeanPostProcessor(new 
BeanPostProcessorChecker(beanFactory, 
beanProcessorTargetCount)); 
/使 用 PriorityOrdered 保 证 顺序 
List<BeanPostProcessor> priorityOrderedPostProcessors = new 
ArrayList<Bean 
PostProcessor>(); 
//MergedBeanDefinitionPostProcessor 
List<BeanPostProcessor> internalPostProcessors = new 
ArrayList<BeanPost 
Processor>(); 
/使 用 Ordered 保 证 顺序 


List<String> orderedPostProcessorNames = new ArrayList<String> 


0; 

/无 序 BeanPostProcessor 

List<String> nonOrderedPostProcessorNames = new 
ArrayList<String>(); 


for (String ppName : postProcessorNames) { 
if (isTypeMatch(ppName, PriorityOrdered.class)) { 
BeanPostProcessor pp = beanFactory.getBean(ppName, 
BeanPostProcessor.class); 
priorityOrderedPostProcessors.add(pp); 
if (pp instanceof MergedBeanDefinitionPostProcessor) { 


internalPostProcessors.add(pp); 


}else if (isTypeMatch(ppName, Ordered.class)) { 


orderedPostProcessorNames.add(ppName); 
jelse { 
nonOrderedPostProcessorNames.add(ppName); 


} 
/第 一 步 ， 注 册 所 有 实现 PriorityOrdered 的 BeanPostProcessor 


OrderComparator.sort(priorityOrderedPostProcessors); 
registerBeanPostProcessors(beanFactory, 
priorityOrderedPostProcessors); 
/第 二 步 ， 注 册 所 有 实现 Ordered 的 BeanPostProcessor 
List<BeanPostProcessor> orderedPostProcessors = new 
ArrayList<BeanPostProcessor>(); 
for (String ppName : orderedPostProcessorNames) { 
BeanPostProcessor pp = beanFactory.getBean(ppName, 
BeanPostProcessor.class); 
orderedPostProcessors.add(pp); 
if (pp instanceof MergedBeanDefinitionPostProcessor) { 


internalPostProcessors.add(pp); 


} 


OrderComparator.sort(orderedPostProcessors); 
registerBeanPostProcessors(beanFactory, orderedPostProcessors); 
/第 三 步 ， 注 册 所 有 无 序 的 BeanPostProcessor 
List<BeanPostProcessor> nonOrderedPostProcessors = new 


ArrayList<BeanPostProcessor>(); 


for (String ppName : nonOrderedPostProcessorNames) { 
BeanPostProcessor pp = beanFactory.getBean(ppName, 
BeanPostProcessor.class); 
nonOrderedPostProcessors.add(pp); 
if (pp instanceof MergedBeanDefinitionPostProcessor) { 


internalPostProcessors.add(pp); 


} 
registerBeanPostProcessors(beanFactory, 
nonOrderedPostProcessors); 
/第 四 步 ， 注 册 所 有 MergedBeanDefinitionPostProcessor 类 型 的 
BeanPostProcessor， 并 非 
重复 注册 ， 
/在 beanFactory.addBeanPostProcessor 中 会 先 移 除 已 经 存在 的 
BeanPostProcessor 
OrderComparator.sort(internalPostProcessors); 
registerBeanPostProcessors(beanFactory, internalPostProcessors); 
/添加 ApplicationListener 探 测 器 
beanFactory.addBeanPostProcessor(new 
ApplicationListenerDetector()); 
} 
配合 源码 以 及 注释 ， 在 registerBeanPostProcessors 方法 中 所 做 的 逻 
辑 相信 大 家 已 经 很 清楚 了 ， 我 们 再 做 一 下 总 结 。 
首先 我 们 会 发 现 ， 对 于 BeanPostProcessor 的 处 理 与 
BeanFactoryPostProcessor 的 处 理 极为 相似 ， 但 是 似乎 又 有 些 不 一 样 的 地 
方 。 经 过 反复 的 对 比 发 现 ， 对 于 BeanFactoryPostProcessor 的 处 理 要 区 分 
两 种 情况 ， 一 种 方式 是 通过 硬 编 码 方式 的 处 理 ， 另 一 种 是 通过 配置 文件 








方式 的 处 理 。 那 么 为 什么 在 BeanPostProcessor 的 处 理 中 只 考虑 了 配置 文 
件 的 方式 而 不 考虑 人 硬 编码 的 方式 呢 ? 提 出 这 个 问题 ， 还 是 因为 读者 没有 
完全 理解 两 者 实现 的 功能 。 对 于 BeanFactoryPostProcessor 的 处 理 ， 不 但 
要 实现 注册 功能 ， 而 且 还 要 实现 对 后 处 理 器 的 激活 操作 ， 所 以 需要 载 入 
配置 中 的 定义 ， 并 进行 激活 ; 而 对 于 BeanPostProcessor 并 不 需要 马上 调 
用 ， 再 说 ， 便 编码 的 方式 实现 的 功能 是 将 后 处 理 器 提取 并 调用 ， 这 里 并 
不 需要 调用 ， 当 然 不 需要 考虑 便 编 码 的 方式 了 ， 这 里 的 功能 只 需要 将 配 
置 文件 的 BeanPostProcessor 提 取出 来 并 注册 进入 beanFactory 就 可 以 了 。 

对 于 beanFactory 的 注册 ， 也 不 是 直接 注册 就 可 以 的 。 在 Spring 中 
文 持 对 于 BeanPost Processor 的 排序 ， 比 如 根据 PriorityOrdered 进 行 排 
序 、 根 据 Ordered 进 行 排序 或 者 无 序 ， 而 Spring 在 BeanPostProcessor 的 激 
活 顺 序 的 时 候 也 会 考虑 对 于 顺序 的 问题 而 先进 行 排序 。 

这 里 可 能 有 个 地 方 读者 不 是 很 理解 ， 对 于 internalPostProcessors 中 
存储 的 后 处 理 器 也 就 是 MergedBeanDefinitionPostProcessor 类 型 的 处 理 
器 ， 在 代码 中 似乎 是 被 重复 调用 了 ， 如 : 


for (String ppName : postProcessorNames) { 

















if (isTypeMatch(ppName, PriorityOrdered.class)) { 

BeanPostProcessor pp = beanFactory.getBean(ppName, 
BeanPostProcessor.class); 
priorityOrderedPostProcessors.add(pp); 
if (pp instanceof MergedBeanDefinitionPostProcessor) { 
internalPostProcessors.add(pp); 

} 

}else if (isTypeMatch(ppName, Ordered.class)) { 
orderedPostProcessorNames.add(ppName); 

}else { 


nonOrderedPostProcessorNames.add(ppName); 


} 
其 实 不 是 ， 我 们 可 以 看 看 对 于 registerBeanPostProcessors 方 法 的 实现 
private void registerBeanPostProcessors( 
ConfigurableListableBeanFactory beanFactory, 
List<BeanPostProcessor> 
postProcessors) { 
for (BeanPostProcessor postProcessor : postProcessors) { 


beanFactory.addBeanPostProcessor(postProcessor); 


} 
public void addBeanPostProcessor(BeanPostProcessor 
beanPostProcessor) { 
Assert.notNull(beanPostProcessor, "BeanPostProcessor must not be 
null"); 
this.beanPostProcessors.remove(beanPostProcessor); 
this.beanPostProcessors.add(beanPostProcessor); 
if (beanPostProcessor instanceof 
InstantiationA wareBeanPostProcessor) { 
this.hasInstantiationA wareBeanPostProcessors = true; 
j 
if (beanPostProcessor instanceof 
DestructionAwareBeanPostProcessor) { 


this.hasDestructionAwareBeanPostProcessors = true; 


} 

可 以 看 到 ， 在 registerBeanPostProcessors 方法 的 实现 中 其 实 已 经 确 
保 了 beanPostProcessor 的 唯一 性 ， 个 人 猜想 ， 之 所 以 选择 在 
registerBeanPostProcessors 中 没有 进行 重复 移 除 操作 或 许 是 为 了 保持 分 
类 的 效果 ， 使 逻辑 更 为 清晰 吧 。 
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在 进行 这 段 函数 的 解析 之 前 ， 我 们 同样 先 来 回顾 Spring 国际 化 的 使 
用 方法 。 

假设 我 们 正在 开发 一 个 支持 多 国语 言 的 Web 应 用 程序 ， 要 求 系统 能 
够 根据 客户 端的 系统 的 语言 类 型 返回 对 应 的 界面 : 英文 的 操作 系统 返回 
英文 界面 ， 而 中 文 的 操作 系统 则 返回 中 文 界面 一 一 这 便 是 典型 的 i18n 国 
际 化 问题 。 对 于 有 国际 化 要 求 的 应 用 系统 ， 我 们 不 能 简单 地 采用 硬 编 码 
的 方式 编写 用 户 界面 信息 、 报 错 信息 等 内 容 ， 而 必须 为 这 些 需要 国际 化 
的 信息 进行 特殊 处 理 。 简 单 来 说 ， 就 是 为 每 种 语言 提供 一 套 相 应 的 资源 
文件 ， 并 以 规范 化 命名 的 方式 保存 在 特定 的 目录 中 ， 由 系统 自动 根据 客 
户 端 语 言 选 择 适 合 的 资源 文件 。 

“国际 化 信息 ”也 称 为 “本 地 化 信息 ”， 一般 需要 两 个 条 件 才 可 以 确定 
一 个 特定 类 型 的 本 地 化 信息 ， 它 们 分 别 是 “语言 类 型 "和 “国家 /地 区 的 类 
型 "?。 如 中 文本 地 化 信息 既 有 中 国 大 陆地 区 的 中 文 ， 又 有 中 国 台 湾 地 
区 、 中 国 香 港 地 区 的 中 文 ， 还 有 新 加 坡地 区 的 中 文 。Java 通过 
java.util.Locale 类 表示 一 个 本 地 化 对 象 ， 它 允许 通过 语言 参数 和 国家 /地 
区 参数 创建 一 个 确定 的 本 地 化 对 象 。 

java.util.Locale 是 表示 语言 和 国家 /地 区 信息 的 本 地 化 类 ， 它 是 创建 
国际 化 应 用 的 基础 。 下 面 给 出 几 个 创建 本 地 化 对 象 的 示例 ; 

//O) 带 有 语言 和 国家 /地 区 信息 的 本 地 化 对 象 


Locale locale1 = new Locale("zh","CN"); 








ID 只 有 语言 信息 的 本 地 化 对 象 

Locale locale2 = new Locale("zh"); 

/K3) = fF] F Locale("zh","CN") 

Locale locale3 = Locale.CHINA; 

/K&) 58 [H]-T- Locale("zh") 

Locale locale4 = Locale.CHINESE; 

UO 获取 本 地 系统 默认 的 本 地 化 对 象 

Locale locale 5= Locale.getDefault(); 

JDK 的 java.util 包 中 提供 了 几 个 支持 本 地 化 的 格式 化 操作 工具 类 : 
NumberFormat, DateFormat, MessageFormat, MÆ Spring 中 的 国际 化 
资源 操作 也 无 非 是 对 于 这 些 类 的 封装 操作 ， 我 们 仅仅 介绍 下 
MessageFormat 的 用 法 以 帮助 大 家 回顾 : 

/信息 格式 化 串 

String pattern] = "{0}， 你 好 ! 你 于 {1} 在 工商 银行 存 入 {2} 6. "5 

String pattern2 = "At {1,time,short} On{1,date,long}, {0} paid 
{2,number, currency }."; 
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Object[] params = {"John", new GregorianCalendar().getTime(),1.0E3}; 

/G) 使 用 默认 本 地 化 对 象 格式 化 信息 

String msg1 = MessageFormat.format(pattern1,params); 

// 思 使 用 指定 的 本 地 化 对 象 格 式 化 信息 


MessageFormat mf = new MessageFormat(pattern2,Locale.US); 











String msg2 = mf.format(params); 

System.out.println(msg1); 

System.out.println(msg2); 

Spring 定义 了 访问 国际 化 信息 的 MessageSource 接口 ， 并 提供 了 几 
个 易 用 的 实现 类 。MessageSource 分 别 被 HierarchicalMessageSource 和 





ApplicationContext 接 口 扩展 ， 这 里 我 们 主要 看 一 下 
HierarchicalMessageSource 接 口 的 几 个 实现 类 ， 如 图 6-3 所 示 。 
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图 6-3 MessageSource 类 图 结构 


HierarchicalMessageSource 接口 最 重要 的 两 个 实现 类 是 
ResourceBundleMessageSource 和 
ReloadableResourceBundleMessageSource。 它 们 基于 Java 的 
ResourceBundle 基 础 类 实现 ， 允 许 仅 通 过 资源 名 加 载 国际 化 资源 。 
ReloadableResourceBundleMessageSource 提 供 了 定时 刷新 功能 ， 人 允许 在 
不 重 司 系统 的 情况 下 ， 更 新 资源 的 信息 。StaticMessageSource 主 要 用 于 
程序 测试 ， 它 允许 通过 编程 的 方式 提供 国际 化 信息 。 而 
DelegatingMessageSource 是 为 方便 操作 父 MessageSource 而 提供 的 代理 
类 。 仅 仅 举例 ResourceBundleMessageSource 的 实现 方式 。 

(1) 定义 资源 文件 。 


messages.properties〈 默 认 : 英文 ) ， 内 容 仅 一 句 ， 如 下 : 

test=test 

messages_zh_CN.properties 〈 人 简体 中 文 ) : 

test= 测 试 

然后 cmd， 打 开 命 令 行 窗口 ， 输 入 native2ascii -encoding gbk 
C:\messages_zh_CN.properties C:\messages_zh_CN_tem.properties ， 并 将 
C:\messages_zh_CN_tem.properties 中 的 内 容 蔡 换 到 
messages zh CN.properties 中 ， 这 样 messages zh CN.properties X fF ii 
存放 的 是 转 码 后 的 内 容 了 ， 比 较 简 单 。 

(2) 定义 配置 文件 。 

<bean id="messageSource" 

class="org.Springframework.context.support.ResourceBundleMessageSource 
<property name="basenames"> 
<list> 
<value>test/messages</value> 
</list> 
</property> 

</bean> 

其 中 ， 这 个 Bean 的 ID 必须 命名 为 messageSource， 人 否则 会 抛 出 
cenae dli E 

(3) 使 用 。 通 过 ApplicationContext 访 问 国际 化 信息 。 

String[] is = {"applicationContext.xml"}; 

ApplicationContext ctx = new 
ClassPathXmlApplicationContext(configs); 

/直接 通过 容器 访问 国际 化 信息 

Object[] params = {"John", new GregorianCalendar().getTime()}; 

String str1 = ctx.getMessage("test",params,Locale.US); 


String str2 = ctx.getMessage("test",params,Locale. CHINA); 

System.out.printIn(str1); 

System.out.println(str2); 

了 解 了 Spring 国际 化 的 使 用 后 便 可 以 进行 源码 的 分 析 了 。 

在 initMessageSource 中 的 方法 主要 功能 是 提取 配置 中 定义 的 
messageSource， 并 将 其 记录 在 Spring 的 容器 中 ， 也 就 是 
AbstractApplicationContext 中 。 当 然 ， 如 果 用 户 未 设置 资源 文件 的 话 ， 
Spring 中 也 提供 了 默认 的 配置 DelegatingMessageSource。 

在 initMessageSource 中 获取 上 自 定 义 资源 文件 的 方式 为 
beanFactory.getBean(MESSAGE_ SOURCE_BEAN_NAME, 
MessageSource.class)， 在 这 里 Spring 使 用 了 硬 编码 的 方式 硬性 规定 了 子 
定义 资源 文件 必须 为 message， 人 否则 便 会 获取 不 到 自 定 义 资源 配置 ， 这 
也 是 为 什么 之 前 提 到 Bean 的 id 如 果 部 位 message 会 抛 出 异常 。 

protected void initMessageSource() { 

ConfigurableListableBeanFactory beanFactory = getBeanFactory(); 
if 
(beanFactory.containsLocalBean(MESSAGE SOURCE BEAN NAME)){ 
/如 果 在 配置 中 已 经 配置 了 messageSource ， 那 么 将 
messageSource 提取 并 记录 在 
this.messageSource 中 
this.messageSource = 
beanFactory.getBean(MESSAGE_SOURCE_BEAN_NAME, 
MessageSource. 
class); 
// Make MessageSource aware of parent MessageSource. 
if (this.parent != null && this.messageSource instanceof 


Hierarchical 


MessageSource) { 
HierarchicalMessageSource hms = 
(HierarchicalMessageSource) this. 
messageSource; 


if (hms.getParentMessageSource() == null) { 


hms.setParentMessageSource(getInternal Parent MessageSource()); 
j 
j 
if (logger.isDebugEnabled()) 1 
logger.debug(" Using MessageSource [" + this.messageSource + 


pee 


}else { 
/如 果 用 户 并 没有 定义 配置 文件 ， 那 么 使 用 临时 的 
DelegatingMessageSource 以 便于 作为 调用 
getMessage 方 法 的 返回 。 


DelegatingMessageSource dms = new 





DelegatingMessageSource(); 
dms.setParentMessageSource(getInternalParentMessageSource()); 


this.messageSource = dms; 


beanFactory.registerSingleton(MESSAGE SOURCE BEAN NAME, 
this.messageSource); 
if (logger.isDebugEnabled()) { 
logger.debug("Unable to locate MessageSource with name ' + 
MESSAGE SOURCE BEAN NAME + 


"using default [" + this.messageSource + "]"); 


} 

通过 读 取 并 将 自 定义 资源 文件 配置 记录 在 容器 中 ， 那 么 就 可 以 在 获 
取 资 源 文件 的 时 候 直接 使 用 了 ， 例 如 ， 在 AbstractApplicationContext 中 
的 获取 资源 文件 属性 的 方法 : 

public String getMessage(String code, Object args[], Locale locale) 
throws NoSuchMessage 

Exception { 

return getMessageSource().getMessage(code, args, locale); 

} 

其 中 的 getMessageSource() 方 法 正 是 获取 了 之 前 定义 的 目 定 义 资 源 配 
Ho- 


6.6.4 初始 化 ApplicationEventMulticaster 
在 讲解 Spring 的 时 间 传 播 器 之 前 ， 我 们 还 是 移 来 看 一 下 Spring 的 事 
件 监 听 的 简单 用 法 。 
(1) 定义 监听 事件 。 
public class TestEvent extends ApplicationEvent { 
public String msg; 
public TestEvent (Object source) { 
super(source); 
j 
public TestEvent (Object source, String msg) 1 
super(source); 


this.msg = msg; 


} 
public void print(){ 
System.out.printIn(msg); 
} 
} 
(20 定义 监听 器。 
public class TestListener implements ApplicationListener { 
public void onApplicationEvent(ApplicationEvent event) { 
if(event instanceof TestEvent){ 
TestEvent testEvent = (TestEvent)event; 


testEvent .print(); 


} 
} 
(3) 添加 配置 文件 。 
<bean id="testListener" class="com.test.event.TestListener "/> 
(4) 测试 。 
public class Test { 
public static void main(String[] args) 1 
ApplicationContext context = new 
ClassPathXmlApplicationContext ("classpath: 
applicationContext.xml"); 


TestEvent event = new TestEvent ("hello","msg"); 


context.publishEvent(event); 


} 
当 程 序 运 行 时 ，Spring 会 将 发 出 的 TestEvent 事 件 转 给 我 们 自 定义 的 


TestListener 进行 进一步 处 理 。 

或 许 很 多 人 一 下 子 会 反映 出 设计 模式 中 的 观察 者 模式 ， 这 确实 是 个 
典型 的 应 用 ， 可 以 在 比较 关心 的 事件 结束 后 及 时 处 理 。 那 么 我 们 看 看 
ApplicationEventMnulticaster 是 如 何 被 初始 化 的 ， 以 确保 功能 的 正确 运 
行 。 

initApplicationEventMmulticaster 的 方式 比较 简单 ， 无 非 考虑 两 种 情 
E 

如 果 用 户 自 定义 了 事件 广播 器 ， 那 么 使 用 用 户 自 定义 的 事件 广播 
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如 果 用 户 没有 自 定 义 事件 广播 占 ， 那 么 使 用 默认 的 
ApplicationEventMulticaster. 
protected void initApplicationEventMulticaster() 1 
ConfigurableListableBeanFactory beanFactory = getBeanFactory(); 
if 
(beanFactory.containsLocalBean( APPLICATION EVENT MULTICASTER 
{ 


this.applicationEventMulticaster = 


beanFactory.getBean(APPLICATION EVENT MULTICASTER, BEAN N. 
ApplicationEventMulticaster.class); 
if (logger.isDebugEnabled()) { 
logger.debug(" Using ApplicationEventMulticaster [" + 
this.application 
EventMulticaster + "|"); 
j 
jelse 1 


this.applicationEventMulticaster = new 


SimpleA pplicationEventMulticaster 
(beanFactory); 


beanFactory.registerSingleton( APPLICATION EVENT MULTICASTER B 
this.applicationEventMulticaster); 
if (logger.isDebugEnabled()) { 
logger.debug(" Unable to locate ApplicationEventMulticaster 
with name "+ 
APPLICATION EVENT MULTICASTER BEAN NAME + 


": using default [" + this.applicationEventMulticaster + "]"); 


} 
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存放 监听 器 并 在 合适 的 时 候 调 用 监听 器 ， 那 么 我 们 不 妨 进入 默认 的 广播 
器 实现 SimpleApplicationEventMulticaster 来 一 探究 竟 。 

其 中 的 一 段 代 码 是 我 们 感 兴趣 的 。 


public void multicastEvent(final ApplicationEvent event) { 





for (final ApplicationListener listener : 
getApplicationListeners(event)) { 
Executor executor = getTaskExecutor(); 
if (executor != null) { 
executor.execute(new Runnable() { 
@SuppressWarnings("“unchecked") 
public void run() { 
listener.onA pplicationEvent(event); 


} 


}); 
} 
else { 


listener.onApplicationEvent(event); 


} 

aJ IEN, E Spring 事件 的 时 候 会 默认 使 用 
SimpleA pplicationEventMulticaster 的 multicastEvent 来 广播 事件 ， 裔 历 所 
有 监听 器 ， 并 使 用 监听 器 中 的 onApplicationEvent 方 法 来 进行 监听 器 的 处 
理 。 而 对 于 每 个 监听 器 来 说 其 实 都 可 以 获取 到 产生 的 事件 ， 但 是 是 个 ; 
行 处 理 则 由 事件 监听 器 来 决定 。 

6.6.5 YE JHH UT à 

之 前 在 介绍 Spring 的 广播 器 时 反复 提 到 了 事件 监听 器 ， 那 么 在 
Spring 注册 监听 器 的 时 候 又 做 了 哪些 逻辑 操作 呢 ? 

protected void registerListeners() { 

// 硬 编码 方式 注册 的 监听 器 处 理 


for (ApplicationListener<?> listener : getApplicationListeners()) { 








getApplicationEventMulticaster().addApplicationListener(listener); 
} 
/配置 文件 注册 的 监听 器 处 理 
String[] listenerBeanNames = 
getBeanNamesForType(ApplicationListener.class, 
true, false); 


for (String lisName : listenerBeanNames) { 


getApplicationEventMulticaster().addApplicationListenerBean(lisName); 
} 
} 
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完成 BeanFactory 的 初始 化 工作 ， 其 中 包括 ConversionService 的 设 
置 、 配 置 冻结 以 及 非 延 人 返 加 载 的 bean 的 初始 化 工作 。 


protected void 





finishBeanFactoryInitialization(ConfigurableListableBeanFactory 
beanFactory) { 

// Initialize conversion service for this context. 

if 
(beanFactory.containsBean(CONVERSION_SERVICE_BEAN_NAME) && 


beanFactory.isTypeMatch(CONVERSION SERVICE BEAN NAME, 
ConversionService.class)) 1 
beanFactory.setConversionService( 
beanFactory.getBean(CONVERSION SERVICE BEAN NAME, 
ConversionService.class)); 
j 
// Initialize LoadTimeWeaverA ware beans early to allow for 
registering their 
transformers early. 
String[] weaverAwareNames = beanFactory.getBeanNamesForType 
(LoadTimeWeaverA ware. 


class, false, false); 


for (String weaverAwareName : weaverAwareNames) { 
getBean(weaverAwareName); 
} 
// Stop using the temporary ClassLoader for type matching. 
beanFactory.setTempClassLoader(null); 
/冻结 所 有 的 bean 定 义 ， 说 明 注册 的 bean 定 义 将 不 被 修改 或 任何 
进一步 的 处 理 。 
beanFactory.freezeConfiguration(); 
// Instantiate all remaining (non-lazy-init) singletons. 
/初始 化 剩 下 的 单 实例 《〈 非 惰性 的 ) 
beanFactory.preInstantiateSingletons(); 
} 
首先 我 们 来 了 解 一 下 ConversionService 类 所 提供 的 作用 。 
1. ConversionService 的 设置 
之 前 我 们 提 到 过 使 用 自 定义 类 型 转换 器 从 String 转 换 为 Date 的 方 
式 ， 那 么 ， 在 Spring 中 还 提供 了 男 一 种 转换 方式 : 使 用 Converter。 同 
样 ， 我 们 使 用 一 个 简单 的 示例 来 了 解 下 Converter 的 使 用 方式 。 
OD iE SUE SR 


public class String2DateConverter implements Converter<String, Date? 


@Override 
public Date convert(String argO) { 
try { 
return DateUtils.parseDate(arg0, 
new String[] { "yyyy-MM-dd HH:mm:ss" }); 
} catch (ParseException e) { 


return null; 


} 
(2) 注册 。 


<bean id="conversionService" 


class="org.Springframework.context.support.ConversionServiceFactoryBean' 
<property name="converters"> 
<list> 
<bean class="String2DateConverter" /> 
</list> 
</property> 
</bean> 
(35 测试 。 
这 样 便 可 以 使 用 Converter 为 我 们 提供 的 功能 了 ， 下 面 我 们 通过 一 
个 简便 的 方法 来 对 此 直接 测试 。 
public void testStringToPhoneNumberConvert() 1 





DefaultConversionService conversionService = new 
DefaultConversionService(); 
conversionService.addConverter(new 
String foPhoneNumberConverter()); 
String phoneNumberStr = "010-12345678"; 
PhoneNumberModel phoneNumber = 
conversionService.convert(phoneNumberStr, PhoneNumber 
Model.class); 
Assert.assertEquals("010", phoneNumber.getAreaCode()); 


通过 以 上 的 功能 我 们 看 到 了 Converter 以 及 ConversionService 提 供 的 
便利 功能 ， 其 中 的 配置 就 是 在 当前 函数 中 被 初始 化 的 。 
2. 冻结 配置 
冻结 所 有 的 bean 定 义 ， 说 明 注 册 的 bean 定 义 将 不 被 修改 或 进行 任何 
进一步 的 处 理 。 
public void freezeConfiguration() { 
this.configurationFrozen = true; 
synchronized (this.beanDefinitionMap) { 
this.frozenBeanDefinitionNames = 
StringUtils.toString Array(this.bean 


DefinitionNames); 


} 

3. 初始 化 非 延 人 运 加 载 

ApplicationContext 实现 的 默认 行为 就 是 在 局 动 时 将 所 有 单 例 bean 
提前 进行 实例 化 。 提 前 实例 化 意味 着 作为 初始 化 过 程 的 一 部 分 ， 
ApplicationContext 实 例会 创建 并 配置 所 有 的 单 例 bean。 通 常情 况 下 这 是 
一 件 好 事 ， 因 为 这 样 在 配置 中 的 任何 错误 就 会 即刻 被 发 现 〈 否 则 的 话 可 
能 要 花 几 个 小 时 甚至 几 天 ) 。 而 这 个 实例 化 的 过 程 就 是 在 
finishBeanFactoryInitialization 中 完成 的 。 





public void preInstantiateSingletons() throws BeansException 1 
if (this. logger.isInfoEnabled()) { 
this.logger.info("Pre-instantiating singletons in " + this); 
} 
List<String> beanNames; 
synchronized (this.beanDefinitionMap) { 


// Iterate over a copy to allow for init methods which in turn 


register new 
bean definitions. 
// While this may not be part of the regular factory bootstrap, it 
does 
otherwise work fine. 
beanNames = new ArrayList<String>(this.beanDefinitionNames); 
} 
for (String beanName : beanNames) { 
RootBeanDefinition bd = 
getMergedLocalBeanDefinition(beanName); 
if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazylnit()) { 
if (isFactoryBean(beanName)) 1 
final FactoryBean<?> factory = (FactoryBean<?>) 
getBean(FACTORY_ 
BEAN_PREFIX + beanName); 
boolean isEagerInit; 
if (System.getSecurityManager() != null && factory 
instanceof 
SmartFactoryBean) { 
isEagerInit = AccessController.doPrivileged(new 
PrivilegedAction 
<Boolean>() { 
public Boolean run() { 
return ((SmartFactoryBean<?>) factory).isEagerInit(); 
} 
}, getAccessControlContext()); 


else { 
isEagerInit = (factory instanceof SmartFactoryBean && 
((SmartFactoryBean<?>) factory).isEagerInit()); 

} 

if (isEagerlInit) { 


getBean(beanName); 


j 
else { 


getBean(beanName); 


6.8 finishRefresh 


在 Spring 中 还 提供 了 Lifecycle 接 口 ，Lifecycle 中 包含 start/stop 方 法 ， 
实现 此 接口 后 Spring 会 保证 在 启动 的 时 候 调 用 其 start 方 法 开始 生命 周 
期 ， 并 在 Spring 关闭 的 时 候 调 用 stop 方 法 来 结束 生命 周期 ， 通 常用 来 配 
置 后 台 程 序 ， 在 局 动 后 一 直 运 行 《 如 对 MQ 进 行 轮 询 等 ) gf 
ApplicationContext 的 初始 化 最 后 正 是 保证 了 这 一 功能 的 实现 。 

protected void finishRefresh() { 





initLifecycleProcessor(); 

// Propagate refresh to lifecycle processor first. 
getLifecycleProcessor().onRefresh(); 

// Publish the final event. 


publishEvent(new ContextRefreshedEvent(this)); 
} 
1. initLifecycleProcessor 
当 ApplicationContext 启 动 或 停止 时 ， 它 会 通过 LifecycleProcessor 来 
与 所 有 声明 的 bean 的 周期 做 状态 更 新 ， 而 在 LifecycleProcessor 的 使 用 前 
首先 需要 初始 化 。 
protected void initLifecycleProcessor() { 
ConfigurableListableBeanFactory beanFactory = getBeanFactory(); 
if 
(beanFactory.containsLocalBean(LIFECYCLE_PROCESSOR_BEAN_NAM 
{ 


this.lifecycleProcessor = 


beanFactory.getBean(LIFECYCLE_PROCESSOR_BEAN_NAME, 
LifecycleProcessor.class); 
if (logger.isDebugEnabled()) { 
logger.debug(" Using LifecycleProcessor [" + 
this.lifecycleProcessor + "]"); 
} 
}else { 
DefaultLifecycleProcessor defaultProcessor = new 
DefaultLifecycleProcessor(); 
defaultProcessor.setBeanFactory(beanFactory); 


this.lifecycleProcessor = defaultProcessor; 


beanFactory.registerSingleton(LIFECYCLE_PROCESSOR_BEAN_NAME, 


this.lifecycleProcessor); 


if (logger.isDebugEnabled()) { 
logger.debug(" Unable to locate LifecycleProcessor with name " 


Y 


LIFECYCLE PROCESSOR BEAN NAME + 
"': using default [" + this.lifecycleProcessor + "]"); 
j 
j 
j 
2. onRefresh 
启动 所 有 实现 了 Lifecycle 接 口 的 bean。 
public void onRefresh() { 
startBeans(true); 
this.running = true; 
} 
private void startBeans(boolean autoStartupOnly) { 
Map<String, Lifecycle» lifecycleBeans = getLifecycleBeans(); 
Map<Integer, LifecycleGroup> phases = new HashMap<Integer, 
LifecycleGroup>(); 


for (Map.Entry<String, ? extends Lifecycle> entry : 
lifecycleBeans.entrySet()) { 
Lifecycle bean = entry.getValue(); 
if (lautoStartupOnly || (bean instanceof SmartLifecycle && 
((SmartLifecycle) 
bean).isAutoStartup())) { 
int phase = getPhase(bean); 
LifecycleGroup group - phases.get(phase); 
if (group == null) { 


group = new LifecycleGroup(phase, 
this.timeoutPerShutdownPhase, 
lifecycleBeans, autoStartupOnly); 
phases.put(phase, group); 
} 
group.add(entry.getKey(), bean); 


} 
if (phases.size() > 0) { 
List<Integer> keys = new ArrayList<Integer>(phases.keySet()); 
Collections.sort(keys); 
for (Integer key : keys) { 
phases.get(key).start(); 


} 
3. publishEvent 
当 完 成 ApplicationContext 初 始 化 的 时 候 ， 要 通过 Spring 中 的 事件 发 
布 机 制 来 发 出 Context RefreshedEvent 事 件 ， 以 保证 对 应 的 监听 器 可 以 做 
进一步 的 逻辑 处 理 。 
public void publishEvent(ApplicationEvent event) { 
Assert.notNull(event, "Event must not be null"); 
if (logger.isTraceEnabled()) { 
logger.trace(" Publishing event in " + getDisplayName() + ": " + 
event); 
j 


getApplicationEventMulticaster().multicastEvent(event); 


if (this.parent != null) { 
this.parent.publishEvent(event); 
} 
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我 们 知道 ， 使 用 面向 对 象 编程 (OOP)〉 有 一 些 浆 端 ， 当 需要 为 多 个 
不 具有 继承 关系 的 对 象 引 入 同一 个 公共 行为 时 ， 例 如 日 志 、 安 全 检测 
等 ， 我 们 只 有 在 每 个 对 象 里 引用 公共 行为 ， 这 样 程序 中 就 产生 了 大 量 的 
重复 代码 ， 程 序 就 不 便于 维护 了 ， 所 以 就 有 了 一 个 对 面向 对 象 编程 的 补 
充 ， 即 面向 方面 编程 CAOPO ，AOP 所 关注 的 方向 是 横向 的 ， 不 同 于 
OOP 的 纵向 。 

Spring 中 提供 了 AOP 的 实现 ， 但 是 在 低 版 本 Spring 中 定义 一 个 切面 
是 比较 麻烦 的 ， 需 要 实现 特定 的 接口 ， 并 进行 一 些 较 为 复杂 的 配置 。 低 
版 本 Spring AOP 的 配置 是 被 批评 最 多 的 地 方 。Spring 听 取 了 这 方面 的 批 
评 声音 ， 并 下 决心 彻底 改变 这 一 现状 。 在 Spring 2.0 中 ，Spring AOPE% 
焕然 一 新 ， 你 可 以 使 用 @AspectJ 注 解 非常 容易 地 定义 一 个 切面 ， 不 需要 
实现 任何 的 接口 。 

Spring 2.0 采 用 @AspectJ 注 解 对 POJO 进 行 标注 ， 从 而 定义 一 个 包含 
切 点 信息 和 增强 横 切 逻辑 的 切面 。Spring 2.0 可 以 将 这 个 切面 织 入 到 匹配 
的 目标 Bean 中 。@AspectJ 注 解 使 用 AspectJ 切 点 表达 式 语法 进行 切 点 定 
义 ， 可 以 通过 切 点 函数 、 运 算 符 、 通 配 符 等 高 级 功能 进行 切 点 定义 ， 拥 
有 强大 的 连接 点 描述 能 力 。 我 们 先 来 直观 地 浏览 一 下 Spring 中 的 AOP 实 
现 。 




















7.1 动态 AOP ZS Bl 


(1) 创建 用 于 拦截 的 bean。 

在 实际 工作 中 ， 此 bean 可 能 是 满足 业务 需要 的 核心 敢 辑 ， 例 如 test 
方法 中 可 能 会 封装 看 茶 个 核心 业务 ， 但 是 ， 如 果 我 们 想 在 test 前 后 加 入 
日 志 来 跟 踊 调 试 ， 如 果 直 接 修改 源码 并 不 符合 面 癌 对 象 的 设计 方法 ， 而 
且 随 意 改 动 原 有 代码 也 会 造成 一 定 的 风险 ， 还 好 接 下 来 的 Spring 玫 我 们 
做 到 了 这 一 点 。 


public class TestBean{ 





private String testStr = "testStr"; 

public String getTestStr() { 
return testStr; 

} 

public void setTestStr(String testStr) { 
this.testStr = testStr; 

} 

public void test()1 


System.out.println(" test"); 


} 

(2) 创建 Advisor。 

Spring 中 据 弃 了 最 原始 的 索 杂 配置 方式 而 采用 @AspectJ 注 解 对 
POJO 进 行 标注 ， 使 AOP 的 工作 大 大 简化 ， 例 如 ， 在 AspectJTest 类 中 ， 
我 们 要 做 的 就 是 在 所 有 类 的 test 方 法 执行 前 在 控制 台中 打印 beforeTest， 
而 在 所 有 类 的 test 方 法 执行 后 打印 afterTest， 同 时 又 使 用 环绕 的 方式 在 所 
有 类 的 方法 执行 前 后 再 次 分 别 打印 before1 和 after1 。 

@Aspect 

public class AspectJTest { 


@Pointcut("execution(* *.test(..))") 


public void test()1 
j 
@Before("test()") 
public void beforeTest()1 
System.out.println("beforeTest"); 
j 
(Q After("test()") 
public void afterTest() { 
System.out.println("afterTest"); 
j 
@Around("test()") 
public Object arountTest(ProceedingJoinPoint p){ 
System.out.println("before1"); 
Object o=null; 
try { 
o = p.proceed(); 
} catch (Throwable e) { 
e.printStackTrace(); 
} 
System.out.println("after1"); 


return 0; 


} 

(3) 创建 配置 文件 。 

XML 是 Spring 的 基础 。 尽 管 Spring 一 再 简化 配置 ， 并 且 大 有 使 用 注 
解 取 代 XML 配 置 之 势 ， 但 是 无 论 如 何 ， 至 少 现在 XML 还 是 Spring 的 基 
础 。 要 在 Spring 中 开启 AOP 功 能 ， 还 需要 在 配置 文件 中 作 如 下 声明 : 








<?xml version="1.0" encoding="UTF-8"?> 

«beans xmlns="http://www.Springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:aop="http://www.Springframework.org/schema/aop" 


xmlns:context="http://www.Springframework.org/schema/context" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www.Springframework.org/schema/beans/Spring-beans- 
3.0.xsd 
http://www.Springframework.org/schema/aop 
http://www.Springframework.org/schema/aop/Spring-aop-3.0.xsd 
http://www.Springframework.org/schema/context 
http://www.Springframework.org/schema/context/Spring- context- 
3.0.xsd 
ins 
<aop:aspectj-autoproxy /> 
<bean id="test" class-"test. TestBean"/» 
<bean class="test.AspectJTest"/> 
</beans> 
(4) 测试。 
经 过 以 上 步骤 后 ， 便 可 以 验证 Spring 的 AOP 为 我 们 提供 的 神奇 效果 


public static void main(String[] args) { 
ApplicationContext bf = new 
ClassPathXmlApplicationContext("aspectTest.xml"); 
TestBean bean=(TestBean) bf.getBean("test"); 
bean.test(); 


} 

不 出 意外 ， 我 们 会 看 到 控制 台中 打印 了 如 下 代码 : 

beforeTest 

before1 

test 

afterTest 

after1 

Spring 实现 了 对 所 有 类 的 test 方 法 进行 增强 ， 使 辅助 功能 可 以 独立 于 
核心 业务 之 外 ， 方 便 与 程序 的 扩展 和 解 耘 。 

那么 ，Spring 究 葛 是 如 何 实现 AOP 的 呢 ? 首先 我 们 知道 ，Spring 是 
否 支 持 注解 的 AOP 是 由 一 个 配置 文件 控制 的 ， 也 就 是 <aop:aspectj- 
autoproxy />， 当 在 配置 文件 中 声明 了 这 句 配 置 的 时 候 ，Spring 就 会 文 持 
注解 的 AOP， 那 么 我 们 的 分 析 就 从 这 人 句 注解 开始 。 











之 前 讲 过 Spring 中 的 自 定 义 注 解 ， 如 果 声 明了 上 自 定义 的 注解 ， 那 么 
就 一 定 会 在 程序 中 的 某 个 地 方 注 册 了 对 应 的 解析 器 。 我 们 搜索 整个 代 
人 码 ， 演 试 找到 注册 的 地 方 ， 全 局 搜索 后 我 们 发 现 了 在 
AopNamespaceHandler 中 对 应 着 这 样 一 段 函 数 : 
public void init() { 
// In 2.0 XSD as well as in 2.1 XSD. 


registerBeanDefinitionParser("config", new 





ConfigBeanDefinitionParser()); 
registerBeanDefinitionParser("aspectj-autoproxy", new 
AspectJAutoProxyBean 


DefinitionParser()); 


registerBeanDefinitionDecorator("scoped-proxy", new 
ScopedProxyBeanDefinition 

Decorator()); 

// Only in 2.0 XSD: moved to context namespace as of 2.1 

registerBeanDefinitionParser("Spring-configured", new 
SpringConfiguredBean 

DefinitionParser()); 

j 

此 处 不 再 对 Spring 中 的 目 定 义 注 解 方式 进行 讨论 。 有 兴趣 的 读者 可 
以 回顾 之 前 的 内 容 。 

我 们 可 以 得 知 ， 在 解析 配置 文件 的 时 候 ， 一 旦 过 到 aspectj- 
autoproxy 注解 时 就 会 使 用 解析 器 AspectJAutoProxyBeanDefinitionParser 
进行 解析 ， 那 么 我 们 来 看 一 看 AspectJAutoProxyBean DefinitionParser 的 
内 部 实现 。 


7.2.1 3 iit AnnotationAwareAspectJAutoProxyC reator 


所 有 解析 器 ， 因 为 是 对 BeanDefinitionParser 接 口 的 统一 实现 ， 入 口 
Ab = M parsers WF 4a), AspectJ AutoProxyBeanDefinitionParserf) parse 
函数 如 下 : 

public BeanDefinition parse(Element element, ParserContext 
parserContext) { 


/注册 AnnotationAwareAspectJAutoProxyCreator 


AopNamespaceUtils.registerAspectJAnnotationAutoProxyCreatorlfNecessary 
(parserContext, element); 
// 对 于 注解 中 子 类 的 处 理 


extendBeanDefinition(element, parserContext); 


return null; 
} 
其 中 registerAspectJAnnotationAutoProxyCreatorlfNecessary 函数 是 
我 们 比较 关心 的 ， 也 是 关键 逻辑 的 实现 。 
Li 
* 注册 AnnotationAwareAspectJAutoProxyCreator 
* @param parserContext 
* @param sourceElement 
*j 
public static void 
registerAspectJAnnotationAutoProxyCreatorIf Necessary( 
ParserContext parserContext, Element sourceElement) 1 
/注册 或 升级 AutoProxyCreator 定义 beanName 为 
org.Springframework.aop.config. 
internal AutoProxyCreatorfJ BeanDefinition 
BeanDefinition beanDefinition = 
AopConfigUtils.registerAspectJAnnotationAuto 
ProxyCreatorlfNecessary( 
parserContext.getRegistry(), 
parserContext.extractSource(sourceElement)); 
/对 于 proxy-target-class 以 及 expose-proxy 属 性 的 处 理 
useClassProxyingIfNecessary(parserContext.getRegistry(), 
sourceElement); 
// 注 册 组 件 并 通知 ， 便 于 监听 器 做 进一步 处 理 
/其 中 beanDefinition 的 className 为 
AnnotationAwareAspectJAutoProxyCreator 


registerComponentlfNecessary(beanDefinition, parserContext); 


} 

在 registerAspectJAnnotationAutoProxyCreatorIfNecessary 方法 中 主 
要 完成 了 3 件 事 情 ， 基 本 上 每 行 代 码 就 是 一 个 完整 的 逻辑 。 

1. 注册 或 者 升级 AnnotationAwareAspectJAutoProxyCreator 

对 于 AOP 的 实现 ， 基 本 上 都 是 靠 
AnnotationAwareAspectJAutoProxyCreator 去 完成 ， 它 可 以 根据 @Point 注 
解 定 义 的 切 点 来 自动 代理 相 匹 配 的 bean。 但 是 为 了 配置 简便 ，Spring 使 
用 了 自 定 义 配 置 来 帮助 我 们 自动 注册 
AnnotationAwareAspectJAutoProxyCreator， 其 注册 过 程 就 是 在 这 里 实现 
的 。 











public static BeanDefinition 
registerAspectJAnnotationAutoProxyCreatorIf Necessary 
(BeanDefinitionRegistry registry, Object source) { 
return 
registerOrEscalateApcAsRequired(AnnotationA wareAspectJ AutoProxyCreat 
class, registry, source); 
j 
private static BeanDefinition registerOrEscalateApcAsRequired(Class 
cls, BeanDefinition 
Registry registry, Object source) 1 
Assert.notNull(registry, "BeanDefinitionRegistry must not be null"); 
/如 果 已 经 存在 了 自动 代理 创建 器 且 存 在 的 自动 代理 创建 器 与 现在 
的 不 一 致 那么 需要 根据 优先 级 来 判断 到 底 需 要 使 用 哪 
if 
(registry.containsBeanDefinition( AUTO_PROXY_CREATOR_BEAN_NAM 
{ 








//AUTO PROXY CREATOR BEAN NAME = 


//"org.Springframework.aop.config.internalAutoProxyCreator"; 
BeanDefinition apcDefinition = 
registry.getBeanDefinition( AUTO PROXY . 
CREATOR BEAN NAME); 
if (!cls.getName().equals(apcDefinition.getBeanClassName())) 1 
int currentPriority — 
findPriorityForClass(apcDefinition.getBean&nbsp;ClassNamer()); 
int requiredPriority = findPriorityForClass(cls); 
if (currentPriority < requiredPriority) { 
/改变 bean 最 重要 的 就 是 改变 bean 所 对 应 的 className 属 性 


apcDefinition.setBeanClassName(cls.getName()); 








/如 果 已 经 存在 目 动 代理 创建 器 并 且 与 将 要 创建 的 一 致 ， 那 么 

无 需 再 此 创建 

return null; 

} 

RootBeanDefinition beanDefinition = new RootBeanDefinition(cls); 

beanDefinition.setSource(source); 

beanDefinition.getProperty Values().add("order", 

Ordered. HIGHEST_PRECEDENCE); 


beanDefinition.setRole(BeanDefinition.ROLE INFRASTRUCTURE); 
//AUTO PROXY CREATOR, BEAN NAME = 


//"org.Springframework.aop.config.internal AutoProxyCreator"; 


registry.registerBeanDefinition(AUTO PROXY CREATOR BEAN NAME 


beanDefinition); 
return beanDefinition; 

} 

以 上 代码 中 实现 了 自动 注册 
AnnotationAwareAspectJAutoProxyCreator 类 的 功能 ， 同 时 这 里 还 涉及 了 
一 个 优先 级 的 问题 ， 如 果 已 经 存在 了 自动 代理 创建 器 ， 而 且 存 在 的 自动 
代理 创建 器 与 现在 的 不 一 致 ， 那 么 需要 根据 优先 级 来 判断 到 底 需 要 使 用 
哪个 。 

2. 处 理 proxy-target-class 以 及 expose-proxy 属 性 

useClassProxyingIfNecessary 实 现 了 proxy-target-class 属 性 以 及 
expose-proxy 属 性 的 处 理 。 


private static void 











UseClassProxyingIfNecessary(BeanDefinitionRegistry registry, Element 
sourceElement) { 
if (sourceElement != null) { 

/对 于 proxyr-target-class 属 性 的 处 理 。 

boolean proxyTargetClass = 
Boolean.valueOf(sourceElement.getA ttribute 

(PROXY TARGET CLASS ATTRIBUTE)); 

if (proxyTargetClass) 1 


AopConfigUtils.forceAutoProxyCreatorToUseClassProxying(registry); 
j 
/对 于 expose-proxy 属 性 的 处 理 
boolean exposeProxy = 
Boolean.valueOf(sourceElement.getAttribute (EXPOSE_ 
PROXY_ATTRIBUTE)); 


让 (exposeProxy) { 


AopConfigUtils.forceAutoProxyCreatorToExposeProxy(registry); 
} 


} 
/强制 使 用 的 过 程 其 实 也 是 一 个 属性 设置 的 过 程 
public static void 
forceAutoProxyCreatorToUseClassProxying(BeanDefinitionRegistry 
registry) 1 
if 
(registry.containsBeanDefinition( AUTO PROXY CREATOR BEAN NAM 
{ 
BeanDefinition definition = 
registry.getBeanDefinition( AUTO PROXY CREATOR 
BEAN NAME); 
definition.getProperty Values().add( "proxy TargetClass", 
Boolean. TRUE); 
j 
j 
static void 
forceAutoProxyCreatorToExposeProxy(BeanDefinitionRegistry registry) { 
if 
(registry.containsBeanDefinition( AUTO PROXY CREATOR BEAN NAM 
{ 
BeanDefinition definition = 
registry.getBeanDefinition( AUTO PROXY CREATOR 


BEAN NAME); 
definition.getProperty Values().add("exposeProxy", 
Boolean. TRUE); 
j 
j 
proxy-target-class: Spring AOP 部 分 使 用 JDK 动 态 代理 或 者 CGLIB 
来 为 目标 对 象 创建 代理 。〔 建 议 尽 量 使 用 JDK 的 动态 代理 ) ， 如 果 被 代 
理 的 目标 对 象 实现 了 至 少 一 个 接口 ， 则 会 使 用 JDK 动 态 代 理 。 所 有 该 目 
标 类 型 实现 的 接口 都 将 被 代理 。 若 该 目标 对 象 没有 实现 任何 接口 ， 则 创 
建 一 个 CGLIB 人 代理。 如 果 你 希望 强制 使 用 CGLIB 人 代理，《 例 如 希望 代理 
目标 对 象 的 所 有 方法 ， 而 不 只 是 实现 自 接口 的 方法 ) 那 也 可 以 。 但 是 需 
要 考虑 以 下 两 个 问题 。 
全 无 法 通知 (advise〉Final 方 法 ， 因 为 它们 不 能 被 窗 写 。 
€ 你 需要 将 CGLIB 二 进 制 发 行 包 放 在 classpath 下 面 。 
与 之 相 较 ，JDK 本 里 就 提供 了 动态 代理 ， 强 制 使 用 CGLIB 代 理 需 要 


将 <aop:config> 的 proxy-target-class 属 性 设 为 true: 








<aop:config proxy-target-class="true"> .… </aop:config> 

当 需 要 使 用 CGLIB 代 理 和 @AspectJ 自 动 代理 支持 ， 可 以 按照 以 下 
方式 设置 <aop:aspectj-autoproxy> 的 proxy-target-class 属 性 : 

<aop:aspectj-autoproxy proxy-target-class="true"/> 

而 实际 使 用 的 过 程 中 才 会 发 现 细节 问题 的 差别 ，The devil is in the 
detail. 

JDK 动 态 代理 : 其 代理 对 象 必 须 是 条 个 接口 的 实现 ， 它 是 通过 在 运 
行 期 间 创 建 一 个 接口 的 实现 类 来 完成 对 目标 对 象 的 代理 。 

CGLIB 代理 : 实现 原理 类 似 于 IDK 动态 代理 ， 只 是 它 在 运行 期 间 
生成 的 代理 对 象 是 针对 目标 类 扩展 的 子 类 。CGLIB 是 高 效 的 代码 生成 
包 ， 底 层 是 依靠 ASM 〈 开 源 的 Java 字 节 码 编辑 类 库 ) 操作 字 节 码 实 现 
































的 ， 性 能 比 JDK 强 。 
expose-proxy: 有 时 候 目 标 对 象 内 部 的 上 自我 调用 将 无 法 实施 切面 中 
的 增强 ， 如 下 示例 : 
public interface AService { 
public void a(); 
public void b(); 
j 
@Service() 
public class AServiceImpl1 implements AService{ 
@Transactional(propagation = Propagation. REQUIRED) 
public void a() 1 
this.b(); 
j 
@Transactional(propagation = Propagation. REQUIRES. NEW) 
public void b() 1 
j 
j 
此 处 的 this 指 向 目标 对 象 ， 因 此 调用 this.b0 将 不 会 执行 b 事 务 切 面 ， 
即 不 会 执行 事务 增强 ， 因 此 b 方 法 的 事务 定 
义 “@Transactional(propagation = Propagation.REQUIRES_NEW)” 将 不 会 
实施 ， 为 了 解决 这 个 问题 ， 我 们 可 以 这 样 做 : 
<aop:aspectj-autoproxy expose-proxy="true"/> 
然后 将 以 上 代码 中 的 “this.b0;” 修 改 为 “((AService) 
AopContext.currentProxy0).b0O;” 即 可 。 通 过 以 上 的 修改 便 可 以 完成 对 a 和 
b 方 法 的 同时 增强 。 
最 后 注册 组 件 并 通知 ， 便 于 监听 器 做 进一步 处 理 ， 这 里 就 不 再 一 一 
BOR T o 





7.3 创建 AOP 代 理 


上 文中 讲解 了 通过 自 定 义 配置 完成 了 对 
AnnotationAwareAspectJAutoProxyCreator 类 型 的 自动 注册 ， 那 么 这 个 类 
到 底 做 了 什么 工作 来 完成 AOP 的 操作 呢 ? 首先 我 们 看 看 Annotation 
AwareAspectJAutoProxyCreator 类 的 层次 结构 ， 如 图 7-1 所 示 。 
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图 7-1 AnnotationAwareAspectJAutoProxyCreator 类 的 层次 结构 图 


在 类 的 层级 中 ， 我 们 看 到 AnnotationAwareAspectJAutoProxyCreator 
实现 了 BeanPostProcessor 接 口 ， 而 实现 BeanPostProcessor 后 ， 当 Spring 
加 载 这 个 Bean 时 会 在 实例 化 前 调用 其 postProcess AfterInitialization 方 
法 ， 而 我 们 对 于 AOP 逻 辑 的 分 析 也 由 此 开始 。 

在 父 类 AbstractAutoProxyCreator 的 postProcessAfterInitialization 中 代 


人 码 如 下 : 


public Object postProcessAfterInitialization(Object bean, String 
beanName) throws BeansException { 
if (bean != null) { 

/根据 给 定 的 bean 的 class 和 name 构 建 出 个 key， 格 式 : 
beanClassName_beanName 

Object cacheKey = getCacheKey(bean.getClass(), beanName); 

if (!this.earlyProxyReferences.contains(cacheKey)) { 

BURR CEE BAER, WU is BEET Re ti FE bean. 


return wrapIfNecessary(bean, beanName, cacheKey); 


} 
return bean; 
} 
protected Object wrapIfNecessary(Object bean, String beanName, 
Object cacheKey) { 
/如 果 已 经 处 理 过 
if (this.targetSourcedBeans.contains(beanName)) { 
return bean; 
} 
/无 需 增 强 
if (this.nonAdvisedBeans.contains(cacheKey)) { 
return bean; 
j 
// 给 定 的 bean 类 是 否 代 表 一 个 基础 设施 类 ， 基 础 设施 类 不 应 代理 ,或 
者 配置 了 指定 bean 不 需要 自动 代理 
if (isInfrastructureClass(bean.getClass()) || 
shouldSkip(bean.getClass(), 





beanName)) { 
this nonAdvisedBeans.add(cacheKey); 
return bean; 
} 
/如 采 存 在 增强 方法 则 创建 代理 
Object[] specificInterceptors = 
getAdvicesAndAdvisorsForBean(bean.getClass(), 
beanName, null); 
/如 果 获 取 到 了 增强 则 需要 针对 增强 创建 代理 
if (specificInterceptors != DO NOT PROXY) { 
this.advisedBeans.add(cacheKey); 
/创建 代理 
Object proxy = createProxy(bean.getClass(), beanName, 
specificInterceptors, 
new SingletonTargetSource(bean)); 
this.proxyTypes.put(cacheKey, proxy.getClass()); 
return proxy; 
} 
this.nonAdvisedBeans.add(cacheK ey); 
return bean; 
j 
函数 中 我 们 已 经 看 到 了 代理 创建 的 锥 形 。 当 然 ， 真正 开始 之 前 还 需 
要 经 过 一 些 判断 ， 比 如 是 否 已 经 处 理 过 或 者 是 否 是 需要 跳 过 的 bean， 而 
真正 创建 代理 的 代码 是 从 getAdvicesAnd AdvisorsForBean 开 始 的 。 
创建 代理 主要 包含 了 两 个 步 又 : 
(1) 获取 增强 方法 或 者 增强 器 ; 
(2) 根据 获取 的 增强 进行 代理 。 





核心 迎 辑 的 时 序 图 如 图 7-2 所 示 。 
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虽然 看 似 简 单 ， 但 是 每 个 步骤 中 都 经 历 了 大 量 复 杂 的 逻辑 。 首 先 来 
看 看 获取 增强 方法 的 实现 逻辑 。 

@Override 

protected Object[] getAdvicesAndAdvisorsForBean(Class beanClass, 
String beanName, 


TargetSource targetSource) { 


List advisors = findEligibleAdvisors(beanClass, beanName); 
if (advisors.isEmpty()) 1 
return DO NOT PROXY; 
j 
return advisors.toArray(); 
j 
protected List<Advisor> findEligibleAdvisors(Class beanClass, String 
beanName) 1 
List<Advisor> candidateA dvisors = findCandidateA dvisors(); 
List<Advisor> eligibleAdvisors = 
findAdvisors ThatCanA pply(candidateAdvisors, 
beanClass, beanName); 
extendAdvisors(eligibleAdvisors); 
if (leligibleAdvisors.isEmpty()) { 
eligibleAdvisors = sortAdvisors(eligibleAdvisors); 
j 
return eligibleAdvisors; 
j 
对 于 指定 bean 的 增强 方法 的 获取 一 定 是 包含 两 个 步骤 的 ， 获 取 所 
有 的 增强 以 及 寻找 所 有 增强 中 适用 于 bean 的 增强 并 应 用 ， 那 么 
findCandidateAdvisors 与 fndAdvisorsThatCanApply 便 是 做 了 这 两 件 事 
情 。 当 然 ， 如 果 无 法 找到 对 应 的 增强 器 便 返 回 DO_NOT_PROXY， 其 中 
DO_NOT_PROXY=null. 


7.3.1 获取 增强 器 
由 于 我 们 分 析 的 是 使 用 注解 进行 的 AOP， 上 所 以 对 于 
findCandidateAdvisors 的 实现 其 实 是 由 








AnnotationAwareAspectJAutoProxyCreator 类 完成 的 ， 我 们 继续 跟踪 
AnnotationAwareAspectJAuto ProxyCreator 的 findCandidateAdvisors 方 
IE. 
@Override 
protected List<Advisor> findCandidateAdvisors() { 
1/2458 FATE AF 77 Zc AOP AY IF AN EE FE S XMLA AY SE 
持 ， 
/在 这 里 调用 父 类 方法 加 载 配置 文件 中 的 AOP 声 明 
List<Advisor> advisors = super.findCandidateAdvisors(); 
// Build Advisors for all AspectJ aspects in the bean factory. 
advisors.addAll(this.aspectJ AdvisorsBuilder.buildAspectJ Advisors()); 
return advisors; 

} 

AnnotationAwareAspectJAutoProxyCreator|i] BE 7K J 
AbstractAdvisorAutoProxyCreator， 在 实现 获取 增强 的 方法 中 除了 保留 父 
类 的 获取 配置 文件 中 定义 的 增强 外 ， 同 时 添加 了 获取 Bean 的 注解 增强 的 
功能 ， 那 么 其 实现 正 是 由 
this.aspectJAdvisorsBuilder.buildAspectJAdvisors() 来 实现 的 。 

在 真正 研究 代码 之 前 读者 可 以 尝试 着 自己 去 想象 一 下 解析 思路 ， 看 
看 目 己 的 实现 与 Spring 是 否 有 差别 呢 ? 或 者 我 们 一 改 以 往 的 方式 ， 先 来 
了 解 函 数 提供 的 大 概 功能 框架 ， 读 者 可 以 在 尖 脑 中 尝试 实现 这 些 功 能 
点 ， 看 看 是 否 有 思路 。 

(1) 获取 所 有 beanName， 这 一 步骤 中 所 有 在 beanFacotry 中 注册 的 
Bean 都 会 被 提取 出 来 。 

(2) 人 表 历 所 有 beanName， 并 找 出 声明 AspectJ 注 解 的 类 ， 进 行进 一 
步 的 处 理 。 

(3) 对 标记 为 AspectJ 注 解 的 类 进行 增强 器 的 提取 。 

















(4) 将 提取 结果 加 入 缓存 。 
现在 我 们 来 看 看 函数 实现 ， 对 Spring 中 所 有 的 类 进行 分 析 ， 提 取 
Advisor。 
public List<Advisor> buildAspectJAdvisors() { 
List<String> aspectNames = null; 
synchronized (this) { 
aspectNames = this.aspectBeanNames; 
if (aspectNames == null) { 
List<Advisor> advisors = new LinkedList<Advisor>(); 
aspectNames = new LinkedList<String>(); 
/获取 所 有 的 beanName 
String[] beanNames 
-BeanFactoryUtils.beanNamesForTypelIncludingAncestors 
(this.beanFactory, Object.class, true, false); 
/循环 所 有 的 beanName 找 出 对 应 的 增强 方法 
for (String beanName : beanNames) { 
/不 合法 的 bean 则 略 过 ， 由 子 类 定义 规则 ， 默 认 返 回 true 
if (lisEligibleBean(beanName)) { 
continue; 
j 
/获取 对 应 的 bean 的 类 型 
Class beanType = this.beanFactory.getl'ype(beanName); 
if (beanType == null) { 
continue; 
} 
/如 果 存 在 Aspect 注 解 
if (this.advisorFactory.isAspect(beanType)) { 


aspectNames.add(beanName); 

AspectMetadata amd = new AspectMetadata(beanType, 

beanName); 

if (amd.getAjType().getPerClause().getKind() == 

PerClauseKind. 

SINGLETON) { 
MetadataAwareAspectInstanceFactory factory = 
new BeanFactoryAspectInstanceFactory(this. 
beanFactory, beanName); 

/解析 标记 AspectJ 注 解 中 的 增强 方法 
List<Advisor> classAdvisors = this.advisorFactory. 
getAdvisors(factory); 
if (this.beanFactory.isSingleton(beanName)) { 
this.advisorsCache.put(beanName, classAdvisors); 
} 
else { 
this.aspectFactoryCache.put(beanName, factory); 
} 
advisors.addAll(classAdvisors); 
}else { 
// Per target or per this. 
if (this.beanFactory.isSingleton(beanName)) { 
throw new IllegalArgumentException("Bean with 
name 
" + beanName + 
"is a Singleton, but aspect instantiation 


model is not singleton"); 


} 

MetadataAwareAspectInstanceFactory factory = 
new PrototypeAspectInstanceFactory(this. 
beanFactory, beanName); 


this.aspectFactoryCache.put(beanName, factory); 


advisors.addAll(this.advisorFactory.getAdvisors(factory)); 
} 


} 
this.aspectBeanNames = aspectNames; 


return advisors; 


} 
if (aspectNames.isEmpty()) { 
return Collections. EMPTY_LIST; 
} 
/记录 在 缓存 中 
List<Advisor> advisors = new LinkedList<Advisor>(); 
for (String aspectName : aspectNames) { 
List<Advisor> cachedAdvisors = 
this.advisorsCache.get(aspectName); 
if (cachedAdvisors != null) { 
advisors.addAll(cachedAdvisors); 
} 
else { 


MetadataA wareAspectInstanceFactory factory = 


this.aspectFactoryCache. 
get(aspectName); 
advisors.addAll(this.advisorFactory.getA dvisors(factory)); 


j 
return advisors; 
j 
至 此 ， 我 们 已 经 完成 了 Advisor 的 提取 ， 在 上 面 的 步骤 中 最 为 重要 
也 最 为 楷 杂 的 就 是 增强 右 的 获取 。 而 这 一 功能 委托 给 了 getAdvisors 方 法 
去 实现 (this.advisorFactory.getAdvisors(factory)) 。 
public List<Advisor> 
getAdvisors(MetadataAwareAspectInstanceFactory maaif) { 
/获取 标记 为 AspectJ 的 类 
final Class<?> aspectClass = 
maaif.getAspectMetadata().getAspectClass(); 
/获取 标记 为 AspectJ 的 name 
final String aspectName = 
maaif.getAspectMetadata().getAspectName(); 
/验证 
validate(aspectClass); 
final MetadataA wareAspectInstanceFactory 
lazySingletonAspectInstanceFactory 
=new LazySingletonAspectInstanceFactoryDecorator(maaif); 
final List<Advisor> advisors = new LinkedList<Advisor>(); 
ReflectionUtils.doWithMethods(aspectClass, new 
ReflectionUtils. MethodCallback() { 
public void doWith(Method method) throws 


IllegalArgumentException 1 
/声明 为 Pointcut 的 方法 不 处 理 
if (AnnotationUtils.getAnnotation(method, Pointcut.class) == 
null) { 
Advisor advisor = getAdvisor(method, 
lazySingletonAspectInstance 
Factory, advisors.size(), aspectName); 
if (advisor != null) { 


advisors.add(advisor); 


j 
y 
if (ladvisors.isEmpty() && 
lazySingletonAspectInstanceFactory.getA spect 
Metadata().isLazilyInstantiated()) 1 
/如 果 寻 找 的 增强 器 不 为 衬 而 且 又 配置 了 增强 延迟 初始 化 那么 
需要 在 首位 加 入 同步 实例 化 增强 器 


Advisor instantiationAdvisor = new SyntheticInstantiationAdvisor 











(lazySingleton 
AspectInstanceFactory); 
advisors.add(0, instantiationAdvisor); 
} 
/获取 DeclareParents 注 解 
for (Field field : aspectClass.getDeclaredFields()) { 
Advisor advisor = getDeclareParentsAdvisor(field); 


if (advisor != null) { 


advisors.add(advisor); 


} 
return advisors; 
} 
函数 中 首先 完成 了 对 增强 器 的 获取 ， 包 括 获 取 注 解 以 及 根据 注解 生 
成 增强 的 步骤 ， 然 后 考 感到 在 配置 中 可 能 会 将 增强 配置 成 延迟 初始 化 ， 
那么 需要 在 首位 加 入 同步 实例 化 增强 器 以 保证 增强 使 用 之 前 的 实例 化 ， 
最 后 是 对 DeclareParents 注 解 的 获取 ， 下 面 将 详细 介绍 一 下 每 个 步 又 。 
1. 普通 增强 器 的 获取 
普通 增强 器 的 获取 逻辑 通过 getAdvisor 方 法 实现 ， 实 现 步 又 包括 对 
切 点 的 注解 的 获取 以 及 根据 注解 信息 生成 增强 。 
public Advisor getAdvisor(Method candidateAdviceMethod, 











MetadataAwareAspectInstanceFactory aif, 
int declarationOrderInAspect, String aspectName) { 
validate(aif.getAspectMetadata().getAspectClass()); 
// 切 点 信息 的 获取 


AspectJExpressionPointcut ajexp = 





getPointcut(candidateAdviceMethod, 
aif.getAspectMetadata().getAspectClass()); 
if (ajexp == null) { 
return null; 
} 
/根据 切 点 信息 生成 增强 器 
return new InstantiationModelA warePointcutAdvisorImpl( 
this, ajexp, aif, candidateAdviceMethod, declarationOrderInA spect, 


aspectName); 


} 
(1) 切 点 信息 的 获取 。 所 谓 获取 切 点 信息 就 是 指定 注解 的 表达 式 
信息 的 获取 ， 如 @Before("test()")。 
private AspectJExpressionPointcut getPointcut(Method 
candidateAdviceMethod, Class<?> 








candidateAspectClass) { 
// 获 取 方 法 上 的 注解 
AspectJAnnotation<?> aspectJAnnotation = 
AbstractAspectJAdvisorFactory.findAspectJ AnnotationOnMethod 
(candidateAdviceMethod); 
if (aspectJAnnotation == null) { 


return null; 


/使 用 AspectJExpressionPointcut 实 例 封装 获取 的 信息 
AspectJExpressionPointcut ajexp = 
new AspectJExpressionPointcut(candidateAspectClass, new 
String[0], 
new Class[0]); 
/提取 得 到 的 注解 中 的 表达 式 如 : 
//@Pointcut("execution(* *.*test*(..))") 中 的 execution(* *.*test*(..)) 
ajexp.setExpression(aspectJAnnotation.getPointcutExpression()); 
return ajexp; 
i 
protected static AspectJAnnotation 
findAspectJAnnotationOnMethod(Method method) { 
/设置 敏感 的 注解 类 


Class«? extends Annotation>[] classesToLookFor = new Class[] { 


Before.class, Around.class, After.class, AfterReturning.class, 
AfterThrowing.class, Pointcut.class}; 

for (Class<? extends Annotation> c : classesToLookFor) { 
AspectJAnnotation foundAnnotation = findAnnotation(method, c); 
if (foundAnnotation != null) { 


return foundAnnotation; 


} 
return null; 
} 
/获取 指定 方法 上 的 注解 并 使 用 AspectJAnnotation 封 装 
private static <A extends Annotation> AspectJAnnotation<A> 
findAnnotation(Method method, 
Class<A> toLookFor) 1 
A result = AnnotationUtils.findAnnotation(method, toLookFor); 
if (result != null) 1 
return new AspectJAnnotation«A (result); 
j 
else { 


return null; 


j 
(20 根据 切 点 信息 生成 增强 。 所 有 的 增强 都 由 Advisor 的 实现 类 
InstantiationModelAware PointcutAdvisorImpl 统 一 封装 的 。 
public 
InstantiationModelA warePointcutAdvisorImpl(AspectJA dvisorFactory af, 


AspectJ 


ExpressionPointcut ajexp, 
MetadataA wareAspectInstanceFactory aif, Method method, int 
declarationOrderInAspect, 

String aspectName) { 

//test() 

this.declaredPointcut = ajexp; 

//public void test.AspectJTest.beforeTest() 
this.method = method; 
this.atAspectJAdvisorFactory = af; 
this.aspectInstanceFactory = aif; 

//0 
this.declarationOrder = declarationOrderInAspect; 
//test.AspectJ Test 
this.aspectName = aspectName; 
if (aif.getAspectMetadata().isLazilyInstantiated()) { 

// Static part of the pointcut is a lazy type. 

Pointcut preInstantiationPointcut = 
Pointcuts.union(aif.getAspectMetadata().getPerClausePointcut(), 
this.declaredPointcut); 

this.pointcut = new 

PerTargetInstantiationModelPointcut(this.declaredPointcut, 
preInstantiationPointcut, aif); 

this.lazy = true; 

jelse 1 
// A singleton aspect. 
this.instantiatedAdvice = instantiateAdvice(this.declaredPointcut); 


this.pointcut = declaredPointcut; 


this.lazy = false; 


} 

在 封装 过 程 中 只 是 简单 地 将 信息 封装 在 类 的 实例 中 ， 所 有 的 信息 单 
纯 地 赋值 ， 在 实例 初始 化 的 过 程 中 还 完成 了 对 于 增强 器 的 初始 化 。 因 为 
不 同 的 增强 所 体现 的 逻辑 是 不 同 的 ， 比 如 @Before (“test()”) 与 
@After (“test()”) 标签 的 不 同 就 是 增强 器 增强 的 位 置 不 同 ， 所 以 就 需要 
不 同 的 增强 器 来 完成 不 同 的 逻辑 ， 而 根据 注解 中 的 信息 初始 化 对 应 的 增 
强 器 就 是 在 instantiateAdvice 函 数 中 实现 的 。 


private Advice instantiateAdvice(AspectJExpressionPointcut pcut) { 








return this.atAspectJAdvisorFactory.getAdvice( 
this.method, pcut, this.aspectInstanceFactory, this.declarationOrder, 
this.aspectName); 
} 
public Advice getAdvice(Method candidateAdviceMethod, 
AspectJExpressionPointcut ajexp, 
MetadataA wareAspectInstanceFactory aif, int 
declarationOrderInAspect, 
String aspectName) 1 
Class«?» candidateAspectClass = 
aif.getAspectMetadata().getAspectClass(); 
validate(candidateAspectClass); 
AspectJAnnotation<?> aspectJAnnotation = 
AbstractAspectJAdvisorFactory.findAspectJAnnotationOnMethod 
(candidate 
AdviceMethod); 


if (aspectJAnnotation == null) { 


return null; 
} 
// If we get here, we know we have an AspectJ method. 
// Check that it's an AspectJ-annotated class 
if ('isAspect(candidateAspectClass)) { 
throw new AopConfigException(" Advice must be declared inside an 
aspect type: " * 
"Offending method "' + candidateAdviceMethod + "in class [" + 
candidateAspectClass.getName() + "|"); 
} 
if (logger.isDebugEnabled()) { 
logger.debug("Found AspectJ method: " + candidateAdviceMethod); 
} 
AbstractAspectJAdvice Spring Advice; 
/根据 不 同 的 注解 类 型 封装 不 同 的 增强 器 
Switch (aspectJAnnotation.getAnnotationType()) { 
case AtBefore: 
Spring Advice = 
newAspectJMethodBeforeAdvice(candidateAdviceMethod, ajexp, aif); 
break; 
case AtAfter: 
Spring Advice = newAspectJAfterAdvice(candidateAdviceMethod, 
ajexp, aif); 
break; 
case AtAfterReturning: 
Spring Advice = 
newAspectJA fterReturning Advice(candidateAdviceMethod, 


ajexp, aif); 
AfterReturning afterReturningAnnotation = (AfterReturning) 
aspectJ Annotation. 
getAnnotation(); 
if (StringUtils.hasText(afterReturningAnnotation.returning())) { 


SpringAdvice.setReturningName(afterReturning Annotation.returning()); 

} 

break; 

case AtAfterThrowing: 

Spring Advice = new 
AspectJAfterThrowingAdvice(candidateAdviceMethod, 

ajexp, aif); 

After Throwing afterThrowingAnnotation = (AfterThrowing) 
aspectJAnnotation. 

getAnnotation(); 

if (StringUtils.hasText(afterThrowingAnnotation.throwing())) { 


SpringAdvice.setl'hrowingName(afterThrowingAnnotation.throwing()); 
j 
break; 
case AtAround: 
SpringAdvice = new 
AspectJAroundAdvice(candidateA dviceMethod, ajexp, aif); 
break; 
case AtPointcut: 
if (logger.isDebugEnabled()) { 


logger.debug(" Processing pointcut " + candidateAdviceMethod. 
getName() + ""); 
} 
return null; 
default: 
throw new UnsupportedOperationException( 
"Unsupported advice type on method " + 
candidateAdviceMethod); 
} 
// Now to configure the advice... 
Spring Advice.setAspectName(aspectName); 
Spring Advice.setDeclarationOrder(declarationOrderInAspect); 
String[] argNames = 
this.parameterNameDiscoverer.getParameterNames (candidateAdvice 
Method); 
if (argNames != null) { 
SpringAdvice.setArgumentNamesFromStringArray(argNames); 
} 
Spring Advice.calculateArgumentBindings(); 
return SpringAdvice; 

} 

从 函数 中 可 以 看 到 ，Spring 会 根据 不 同 的 注解 生成 不 同 的 增强 器 ， 
例如 AtBefore 会 对 应 AspectJMethodBeforeAdvice， 而 在 
AspectJMethodBeforeAdvice 中 完成 了 增强 方法 的 逻辑 。 我 们 尝试 分 析 下 
几 个 第 用 的 增强 器 实现 。 

MethodBeforeAdviceInterceptor。 

我 们 首先 查看 MethodBeforeAdviceInterceptor 类 的 内 部 实现 。 


public class MethodBeforeAdviceInterceptor implements 
MethodInterceptor, Serializable { 
private MethodBeforeAdvice advice; 
[ee 
* Create anew MethodBeforeAdvicelnterceptor for the given 
advice. 
* @param advice the MethodBeforeAdvice to wrap 
gi 
public MethodBeforeAdviceInterceptor(MethodBeforeAdvice 
advice) { 
Assert.notNull(advice, "Advice must not be null"); 
this.advice = advice; 
} 
public Object invoke(MethodInvocation mi) throws Throwable { 
this.advice.before(mi.getMethod(), mi.getArguments(), 
mi.getThis() ); 


return mi.proceed(); 


} 

其 中 的 属性 MethodBeforeAdvice 代表 着 前 置 增强 的 
AspectJMethodBeforeAdvice， 跟 踪 before 方 法 : 

public void before(Method method, Object[] args, Object target) throws 
Throwable { 

invokeAdviceMethod(getJoinPointMatch(), null, null); 
} 
protected Object invokeAdviceMethod(JoinPointMatch jpMatch, Object 


returnValue, Throwable 


ex) throws Throwable { 
return 
invokeAdviceMethodWithGivenArgs(argBinding(getJoinPoint(), jpMatch, 
returnValue, ex)); 
} 
protected Object invokeAdviceMethodWithGivenArgs(Object[] args) 
throws Throwable { 
Object[] actualArgs = args; 
if (this.aspectJAdviceMethod.getParameterTypes().length == 0) { 
actualArgs = null; 
} 
try { 
ReflectionUtils.makeA ccessible(this.aspectJ AdviceMethod); 
/激活 增强 方法 
return 
this.aspectJ AdviceMethod.invoke(this.aspectInstanceFactory. getAspect 
Instance(), actualArgs); 
} 
catch (IllegalArgumentException ex) { 
throw new AopInvocationException(" Mismatch on arguments to 
advice method [" + 
this.aspectJAdviceMethod + "]; pointcut expression [" + 
this.pointcut.getPointcutExpression() + "|", ex); 
j 
catch (InvocationTargetException ex) 1 


throw ex.getTargetException(); 


} 

invokeAdviceMethodWithGivenArgs7; 1; # HJ aspectJ AdviceMethod iE 
是 对 于 前 置 增强 的 方法 ， 在 这 里 实现 了 调用 。 

AspectJAfterAdvice. 

后 置 增强 与 前 置 增强 有 稍 许 不 一 致 的 地 方 。 回 顾 之 前 讲 过 的 前 置 增 
强 ， 大 人 致 的 结构 是 在 拦截 器 链 中 放置 MethodBeforeAdviceInterceptor， 而 
在 MethodBeforeAdviceInterceptor 中 又 放置 了 
AspectJMethodBeforeAdvice， 并 在 调用 invoke 时 首先 串联 调用 。 但 是 在 
后 置 增强 的 时 候 却 不 一 样 ， 没 有 提供 中 间 的 类 ， 而 是 直接 在 拦截 器 链 中 
使 用 了 中 间 的 AspectJAfterAdvice。 

public class AspectJAfterAdvice extends AbstractAspectJAdvice 











implements MethodInterceptor, 
AfterAdvice { 
public AspectJA fterAdvice( 
Method aspectJBeforeAdviceMethod, AspectJExpressionPointcut 
pointcut, 
AspectInstanceFactory aif) { 
super(aspectJBeforeAdviceMethod, pointcut, aif); 
} 
public Object invoke(MethodInvocation mi) throws Throwable { 
try { 
return mi.proceed(); 
} 
finally { 
/激活 增强 方法 
invokeAdviceMethod(getJoinPointMatch(), null, null); 


} 

public boolean isBeforeAdvice() { 
return false; 

} 

public boolean isAfterAdvice() { 


return true; 


} 

2. 增加 同步 实例 化 增强 器 

如 末 寻 找 的 增强 噩 不 为 空 而 且 又 配置 了 增强 延迟 初始 化 ， 那 么 就 需 
要 在 首位 加 入 同步 实例 化 增强 器 。 同 步 实例 化 增强 器 
SyntheticInstantiationAdvisor 如 下 : 











protected static class SyntheticInstantiationAdvisor extends 
DefaultPointcutAdvisor { 
public SyntheticInstantiationAdvisor(final 
MetadataA wareAspectInstanceFactory aif) { 
super(aif.getAspectMetadata().getPerClausePointcut(), new 

MethodBeforeAdvice() { 

/目标 方法 前 调用 ， 类 似 @Before 

public void before(Method method, Object[] args, Object target) 


/简单 初始 化 aspect 
aif.getAspectInstance(); 


D; 


3. 获取 DeclareParents 注 解 
DeclareParents 主 要 用 于 引 介 增 强 的 注解 形式 的 实现 ， 而 其 实现 方式 
与 普通 增强 很 类 似 ， 只 不 过 使 用 DeclareParentsAdvisor 对 功能 进行 圭 
装 。 
private Advisor getDeclareParentsAdvisor(Field introductionField) { 
DeclareParents declareParents = (DeclareParents) 
introductionField.getAnnotation 
(DeclareParents.class); 
if (declareParents == null) { 
// Not an introduction field 
return null; 
} 
if (DeclareParents.class.equals(declareParents.defaultImpl())) { 
// This is what comes back if it wasn't set. This seems bizarre... 
// TODO this restriction possibly should be relaxed 
throw new IllegalStateException("defaultImpl must be set on 
Declare 
Parents"); 
j 


return new DeclareParentsAdvisor( 


introductionField.getType(), declareParents.value(), declareParents. 
defaultImpl()); 





前 面 的 函数 中 已 经 完成 了 所 有 增强 器 的 解析 ， 但 是 对 于 所 有 增强 器 
来 讲 ， 并 不 一 定 都 适用 于 当前 的 Bean， 还 要 挑 取出 适合 的 增强 器 ， 也 就 


是 满足 我 们 配置 的 通配符 的 增强 器。 具体 实现 在 
findAdvisorsThatCanApply 中 。 
protected List<Advisor> findAdvisorsThatCanApply( 
List<Advisor> candidateAdvisors, Class beanClass, String beanName) { 
ProxyCreationContext.setCurrentProxiedBeanName(beanName); 
try 1 
/过 滤 已 经 得 到 的 advisors 
return AopUtils.findAdvisorsThatCanA pply(candidateAdvisors, 
beanClass); 
j 
finally 1 


ProxyCreationContext.setCurrentProxiedBeanName(null); 


} 
4k 22 4 find AdvisorsThatCanApply: 
public static List<Advisor> findAdvisorsThatCanApply(List<Advisor> 
candidateAdvisors, 
Class<?> clazz) { 
if (candidateAdvisors.isEmpty()) { 
return candidateAdvisors; 
} 
List<Advisor> eligibleAdvisors = new LinkedList<Advisor>(); 
/首先 处 理 引 介 增 强 
for (Advisor candidate : candidateAdvisors) { 
if (candidate instanceof IntroductionAdvisor && 
canApply(candidate, clazz)) { 
eligibleAdvisors.add(candidate); 


} 
boolean hasIntroductions = !eligibleAdvisors.isEmpty(); 
for (Advisor candidate : candidateAdvisors) { 
/ 引 介 增强 已 经 处 理 
让 (candidate instanceof IntroductionAdvisor) { 
continue; 
} 
/对 于 普通 bean 的 处 理 
让 (canApply(candidate, clazz, hasIntroductions)) { 
eligibleAdvisors.add(candidate); 


} 


return eligibleAdvisors; 


findAdvisorsThatCanApply 函数 的 主要 功能 是 寻找 所 有 增强 器 中 适 
用 于 当前 class 的 增强 器 。 引 介 增 强 与 普通 的 增强 是 处 理 不 一 样 的 ， 所 
以 分 开 处 理 。 而 对 于 真正 的 匹配 在 canApply 中 实现 。 


public static boolean canApply(Advisor advisor, Class<?> targetClass, 


boolean 


hasIntroductions) { 


if (advisor instanceof IntroductionAdvisor) { 


return ((IntroductionAdvisor) advisor).getClassFilter().matches 


(targetClass); 


Jelse if (advisor instanceof PointcutAdvisor) 1 
PointcutAdvisor pca = (PointcutAdvisor) advisor; 


return canApply(pca.getPointcut(), targetClass, hasIntroductions); 


}else { 
// It doesn't have a pointcut so we assume it applies. 


return true; 


} 
public static boolean canApply(Pointcut pc, Class<?> targetClass, 
boolean hasIntroductions) { 
Assert.notNull(pc, "Pointcut must not be null"); 
if (!pc.getClassFilter().matches(targetClass)) 1 
return false; 
j 
MethodMatcher methodMatcher = pc.getMethodMatcher(); 
IntroductionA wareMethodMatcher 
introductionAwareMethodMatcher = null; 
if (methodMatcher instanceof IntroductionAwareMethodMatcher) { 
introductionA wareMethodMatcher = 
(IntroductionAwareMethodMatcher) methodMatcher; 
} 
Set<Class> classes = new HashSet<Class> 
(ClassUtils.getAllInterfacesForClassAsSet 
(targetClass)); 
classes.add(targetClass); 
//classes:[interface test.ITTestBean, class test. TestBean] 
for (Class<?> clazz : classes) 1 
Method[] methods = clazz.getMethods(); 
for (Method method : methods) { 
if ((introductionA wareMethodMatcher != null && 


introductionA wareMethodMatcher.matches(method, 


targetClass, 


hasIntroductions)) || 
methodMatcher.matches(method, targetClass)) { 


return true; 


} 


return false; 


} 
7.3.3 创建 代理 
在 获取 了 所 有 对 应 bean 的 增强 器 后 ， 便 可 以 进行 代理 的 创建 了 。 


protected Object createProxy( 


Class<?> beanClass, String beanName, Object[] specificInterceptors, 


TargetSource 


PE, 


targetSource) 1 
ProxyFactory proxyFactory = new ProxyFactory(); 
/获取 当前 类 中 相关 属性 
proxyFactory.copyFrom(this); 
/决定 对 于 给 定 的 bean 是 否 应 该 使 用 targetClass 而 不 是 他 的 接口 代 





/检查 proxyTargeClass 设 置 以 及 preserveTargetClass 属 性 
if (!shouldProxyTargetClass(beanClass, beanName)) { 
// Must allow for introductions; can't just set interfaces to 
// the target's interfaces only. 


Class<?>[] targetInterfaces = 


ClassUtils.getAllInterfacesForClass(beanClass,&nbsp;this.proxyClassLoader) 
for (Class<?> targetInterface : targetInterfaces) 1 
// 添 加 代理 接口 


proxyFactory.addInterface(targetInterface); 


} 


Advisor[] advisors = buildAdvisors(beanName, specificInterceptors); 
for (Advisor advisor : advisors) { 
INT v d 
proxyFactory.addAdvisor(advisor); 
} 
/设置 要 代理 的 类 
proxyFactory.setTargetSource(targetSource); 
/定制 代理 
customizeProxyFactory(proxyFactory); 
// 用 来 控制 代理 工厂 被 配置 之 后 ， 是 否 还 允许 修改 通知 。 
// 缺 省 值 为 false〈 即 在 代理 被 配置 之 后 ， 不 允许 修改 代理 的 配 








BL 
proxyFactory.setFrozen(this.freezeProxy); 
if (advisorsPreFiltered()) 1 
proxyFactory.setPreFiltered(true); 
j 
return proxyFactory.getProxy(this.proxy ClassLoader); 
j 
对 于 代理 类 的 创建 及 处 理 ，Spring 委 托 给 了 ProxyFactory 去 处 理 ， 而 
在 此 函数 中 主要 是 对 ProxyFactory 的 初始 化 操作 ， 进 而 对 真正 的 创建 代 
理 做 准备 ， 这 些 初始 化 操作 包括 如 下 内 容 。 


(1) 获取 当前 类 中 的 属性 。 

(2) 添加 代理 接口 。 

(3) 封装 Advisor 并 加 入 到 ProxyFactory 中 。 

(4) 设置 要 代理 的 类 。 

(5) 当然 在 Spring 中 还 为 子 类 提供 了 和 定制 的 函数 
customizeProxyFactory， 子 类 可 以 在 此 函数 中 进行 对 ProxyFactory 的 进 一 
HFR. 

(6) 进行 获取 代理 操作 。 

其 中 ， 封 装 Advisor 并 加 入 到 ProxyFactory 中 以 及 创建 代理 是 两 个 相 
对 繁 玉 的 过 程 ， 可 以 通过 ProxyFactory 提 供 的 addAdvisor 方 法 直接 将 增强 
器 置 入 代理 创建 工厂 中 ， 但 是 将 拦截 器 封装 为 增强 器 还 是 需要 一 定 的 尿 
辑 的 。 

protected Advisor[] buildAdvisors(String beanName, Object[j 





specificInterceptors) { 
/解析 注册 的 所 有 interceptorName 
Advisor[] commonInterceptors = resolveInterceptorNames(); 
List<Object> allInterceptors = new ArrayList<Object>(); 
if (specificInterceptors != null) { 
// 加 入 拦截 器 
allInterceptors.addAll(Arrays.asList(specificInterceptors)); 
if (commonInterceptors != null) { 
if (this.applyCommonInterceptorsFirst) 1 
allInterceptors.addAIl(0, 
Arrays.asList(commonInterceptors)); 
} 
else { 


allInterceptors.addAll(Arrays.asList(commonlInterceptors)); 


} 
if (logger.isDebugEnabled()) { 
int nrOfCommonInterceptors = (commonlInterceptors != null ? 
commoninterceptors. 
length : 0); 
int nrOfSpecificInterceptors = (specificInterceptors != null ? 
specificInterceptors. 
length : 0); 
logger.debug(" Creating implicit proxy for bean ™ + beanName + "' 
with " + 
nrOfCommonInterceptors + 
" common interceptors and " + nrOfSpecificInterceptors + " 
specific 
interceptors"); 
} 
Advisor[] advisors = new Advisor[allInterceptors.size() |; 
for (int i = 0; i < allInterceptors.size(); i++) { 
/拦截 器 进行 封装 转化 为 Advisor 
advisors[i] = 
this.advisorAdapterRegistry.wrap(allInterceptors.get(1)); 
j 
return advisors; 
j 
public Advisor wrap(Object adviceObject) throws 
UnknownAdviceTypeException 1 





/如 果 要 封装 的 对 象 本 身 就 是 Advisor 类 型 的 那么 无 需 再 做 过 多 处 
理 
if (adviceObject instanceof Advisor) { 
return (Advisor) adviceObject; 
} 
/因为 此 封装 方法 只 对 Advisor 与 Advice 两 种 类 型 的 数据 有 效 ， 如 
条 不 是 将 不 能 封装 
if (!(adviceObject instanceof Advice)) { 
throw new UnknownAdviceTypeException(adviceObject); 
} 
Advice advice = (Advice) adviceObject; 
if (advice instanceof MethodInterceptor) { 
/如 果 是 MethodInterceptor 类 型 则 使 用 DefaultPointcutAdvisor 封 


return new DefaultPointcutAdvisor(advice); 
} 
// 如 果 存 在 Advisor 的 适配器 那么 也 同样 需要 进行 封装 
for (AdvisorAdapter adapter : this.adapters) { 





// Check that it is supported. 
if (adapter.supportsAdvice(advice)) { 


return new DefaultPointcutAdvisor(advice); 


} 
throw new UnknownAdviceTypeException(advice); 
} 
HT Spring Pit Ate Wa. Soa. TSR AEN DOOR ME 
辑 进行 增强 ， 所 以 非常 有 必要 统一 封装 成 Advisor 来 进行 代理 的 创建 ， 








完成 了 增强 的 封 闵 过程， 那么 解析 最 重要 的 一 步 就 是 代理 的 创建 与 获取 
Kg 
public Object getProxy(ClassLoader classLoader) 1 
return createAopProxy().getProxy(classLoader); 
j 
1. 创建 代理 
protected final synchronized AopProxy createAopProxy() { 
if (Ithis.active) { 
activate(); 
} 
/创建 代理 
return getAopProxyFactory().createAopProxy(this); 
} 
public AopProxy createAopProxy(AdvisedSupport config) throws 
AopConfigException { 
if (config.isOptimize() || config.isProxyTargetClass() || 
hasNoUserSuppliedProxy 
Interfaces(config)) { 
Class targetClass = config.getTargetClass(); 
if (targetClass == null) { 
throw new AopConfigException("TargetSource cannot 
determine target class: " + 
"Either an interface or a target is required for proxy 
creation."); 
j 
if (targetClass.isInterface()) 1 


return new JdkDynamicAopProxy(config); 


} 
if (!IcglibAvailable) { 
throw new AopConfigException( 


"Cannot proxy target class because CGLIB2 is not available. 


"Add CGLIB to the class path or specify proxy interfaces."); 
} 
return CglibProxyFactory.createCglibProxy(config); 
} 
else { 


return new JdkDynamicAopProxy(config); 


} 

到 此 已 经 完成 了 代理 的 创建 ， 不 管 我 们 之 前 是 否 有 阅读 过 Spring 的 
源 代 码 ， 但 是 都 或 多 或 少 地 听 过 对 于 Spring 的 代理 中 JDKProxy 的 实现 和 
CglibProxy 的 实现 。Spring 是 如 何 选取 的 呢 ? 网 上 的 介绍 到 处 都 是 ， 现 
在 我 们 就 从 源 代 人 码 的 角度 分 析 ， 看 看 到 底 Spring 是 如 何 选择 代理 方式 
的 。 

从 if 中 的 判断 条 件 可 以 看 到 3 个 方面 影响 着 Spring 的 判断 。 

optimize: 用 来 控制 通过 CGLIB 创 建 的 代理 是 否 使 用 激进 的 优化 策 
略 。 除 非 完 全 了 解 AOP 代 理 如 何 处 理 优化 ， 否 则 不 推荐 用 户 使 用 这 个 设 
置 。 目 前 这 个 属性 仅 用 于 CGLIB 代 理 ， 对 于 JDK 动 态 代理 〔 缺 省 代理 ) 
元 


proxyTargetClass: 这 个 属性 为 true 时 ， 目 标 类 本 身 被 代理 而 不 是 目 
标 类 的 接口 。 如 果 这 个 属性 值 被 设 为 rue，CGLIB 代理 将 被 创建 ， 设 置 
方式 : <aop:aspectj-autoproxy proxy-target-class="true"/>。 
hasNoUserSuppliedProxyInterfaces: 是 否 存在 代理 接口 。 


下 面 是 对 JDK 与 Cglib 方 式 的 总 结 。 
如 有 果 目 标 对 象 实现 了 接口 ， 默 认 情 况 下 会 采用 JDK 的 动态 代理 实现 
AOP. 
如 果 目 标 对 象 实现 了 接口 ， 可 以 强制 使 用 CGLIB 实 现 AOP。 
如 果 目 标 对 象 没 有 实现 了 接口 ， 必 须 采 用 CGLIB 库 ，Spring 会 自动 
在 JDK 动 态 代理 和 CGLIB 之 间 转 换 。 
如 何 强制 使 用 CGLIB 实 现 AOP? 
(1) 添加 CGLIB 库 ，Spring_HOME/cglib/*.jar。 
(2) 在 Spring 配 置 文件 中 加 入 <aop:aspectj-autoproxy proxy-target- 
class="true"/>。 
JDK 动 态 代 理 和 CGLIB 字 节 码 生成 的 区 别 ? 
JDK 动 态 代理 只 能 对 实现 了 接口 的 类 生成 代理 ， 而 不 能 针对 类 。 
CGLIB 是 针对 类 实现 代理 ， 主 要 是 对 指定 的 类 生成 一 个 子 类 ， 上 罗 盖 
其 中 的 方法 ， 因 为 是 继承 ， 所 以 该 类 或 方法 最 好 不 要 声明 成 final。 
2. 获取 代理 
确定 了 使 用 哪 种 代理 方式 后 便 可 以 进行 代理 的 创建 了 了， 但 是 创建 之 
前 有 必要 回顾 一 下 两 种 方式 的 使 用 方法 。 
(1) JDK 代 理 使 用 示例 。 
创建 业务 接口 ， 业 务 对 外 提供 的 接口 ， 包 含 着 业务 可 以 对 外 提供 的 














public interface UserService { 
[RK 
月 标 广 法 
*/ 
public abstract void add(); 
} 
创建 业务 接口 实现 类 。 


public class UserServiceImpl implements UserService { 
/* (non-Javadoc) 
* @see dynamic.proxy.UserService#add() 
*/ 
public void add() { 
System.out.println("-------------------- add--------------- p 


j 
创建 自 定 义 的 InvocationHandler， 用 于 对 接口 提供 的 方法 进行 增 
JH 
public class MyInvocationHandler implements InvocationHandler 1 
/ 目标 对 象 
private Object target; 
pee 
* 构造 方法 
* @param target 目 标 对 象 
*/ 
public MyInvocationHandler(Object target) { 
super(); 
this.target = target; 
} 
pee 
* 执行 目标 对 象 的 方法 
*/ 
public Object invoke(Object proxy, Method method, Object[] args) 
throws Throwable { 


/在 目标 对 象 的 方法 执行 之 前 简单 的 打印 一 下 


System.out.println("------------------ before------------------ "); 
/ 执行 目标 对 象 的 方法 
Object result = method.invoke(target, args); 
/在 目标 对 象 的 方法 执行 之 后 简单 的 打印 一 下 
System.out.println("------------------- after------------------ zs 
return result; 
j 
Li 
* 获取 目标 对 象 的 代理 对 象 
* Oreturn 代 理 对 象 
*/ 
public Object getProxy() { 
return 
Proxy.newProxyInstance(Thread.currentThread().getContextClassLoader(), 


target.getClass().getInterfaces(), this); 


} 
最 后 进行 测试 ， 验 证 对 于 接口 的 增强 是 否 起 到 作用 。 
public class ProxyTest { 
@Test 
public void testProxy() throws Throwable { 
/ 实例 化 目标 对 象 
UserService userService = new UserServiceImpl(); 
// 实例 化 InvocationHandler 
MyInvocationHandler invocationHandler = new 


MylInvocationHandler(userService); 


/根据 目标 对 象 生成 代理 对 象 


UserService proxy = (UserService) invocationHandler.getProxy(); 
/ 调用 代理 对 象 的 方法 
proxy.add(); 


} 
执行 结果 如 下 : 


用 起 来 很 简单 ， 其 实 这 基本 上 就 是 AOP 的 一 个 简单 实现 了 ， 在 目 
标 对 象 的 方法 执行 之 前 和 执行 之 后 进行 了 增强 。Spring 的 AOP 实 现 其 实 
也 是 用 了 Proxy 和 InvocationHandler 这 两 个 东西 的 。 

我 们 再 次 来 回顾 一 下 使 用 JDK 代理 的 方式 ， 在 整个 创建 过 程 中 ， 
对 于 InvocationHandler 的 创建 是 最 为 核心 的 ， 在 自 定 义 的 
InvocationHandler 中 需要 重 写 3 个 函数 。 

构造 函数 ， 将 代理 的 对 象 传 入 。 

invoke 方 法 ， 此 方法 中 实现 了 AOP 增 强 的 所 有 氨 辑 。 

getProxy 方 法 ， 此 方法 千篇一律 ， 但 是 必 不 可 少 。 

那么 ， 我 们 看 看 Spring 中 的 JDK 代 理 实现 是 不 是 也 是 这 么 做 的 呢 ? 
继续 之 前 的 跟踪 ， 到 达 JdkDynamicAopProxy 的 getProxy。 

public Object getProxy(ClassLoader classLoader) { 

if (logger.isDebugEnabled()) { 
logger.debug(" Creating JDK dynamic proxy: target source is " + 











this. 
advised.getTargetSource()); 
} 


Class[] proxiedInterfaces = 


AopProxyUtils.completeProxiedInterfaces(this.advised); 
findDefinedEqualsAndHashCodeMethods(proxiedInterfaces); 


return Proxy.newProxyInstance(classLoader, proxiedInterfaces, this); 


通过 之 前 的 示例 我 们 知道 ，JDKProxy 的 使 用 关键 是 创建 自 定 义 的 
InvocationHandler， 而 InvocationHandler FAS Y 55228 ss HY eh Be 
getProxy， 而 当前 的 方法 正 是 完成 了 这 个 操作 。 再 次 确认 一 下 
JdkDynamicAopProxy 也 确实 实现 了 InvocationHandler 接 口 ， 那 么 我 们 就 
可 以 推断 出 ， 在 JdkyDynamicAopProxy 中 一 定 会 有 个 invoke 函 数 ， 并 且 
J ns 会 把 AOP 的 核心 逻辑 写 在 其 中 。 查 看 代码 ， 果 然 有 

这 样 个 函数 : 

public Object invoke(Object proxy, Method method, Object[] args) 








throws Throwable { 
MethodInvocation invocation; 
Object oldProxy = null; 
boolean setProxyContext = false; 
TargetSource targetSource = this.advised.targetSource; 
Class targetClass = null; 
Object target = null; 
try { 
//equals 方 法 的 处 理 
if (!this.equalsDefined && AopUtils.isEqualsMethod(method)) { 
return equals(args[0]); 
j 
/hash 方 法 的 处 理 
if (!this.hashCodeDefined && 
AopUtils.isHashCodeMethod(method)) { 


return hashCode(); 
} 
p 
* Class 类 的 isAssignableFrom(Class cls) 方 法 : 
* 如 果 调 用 这 个 方法 的 dlass 或 接口 与 参数 ds 表示 的 类 或 接口 








相同 ， 

* 或 者 是 参数 cls 表 示 的 类 或 接口 的 父 类 ， 则 返回 true。 

* 形象 地 : 自身 类 .class.isAssignableFrom( 自 身 类 或 子 类 .class) 
返回 true 

* il: 

* 


System.out.println(ArrayList.class.isAssignableFrom(Object.class)); 
//false 
* 
System.out.printIn(Object.class.isAssignableFrom(ArrayList.class)); 
//true 
*/ 
if (!this.advised.opaque && method.getDeclaringClass().isInterface() 
&& method.getDeclaringClass().isAssignableFrom(Advised.class)) { 
return AopUtils.invokeJoinpointUsingReflection(this.advised, 
method, args); 
} 
Object retVal; 
/有 时 候 目标 对 象 内 部 的 自我 调用 将 无 法 实施 切面 中 的 增强 则 需 
EVAL VJ VER Be TER 
if (this.advised.exposeProxy) { 
oldProxy = AopContext.setCurrentProxy(proxy); 


setProxyContext = true; 
} 
target = targetSource.getTarget(); 
if (target != null) { 
targetClass = target.getClass(); 
} 
/获取 当前 方法 的 拦截 器 链 
List<Object> chain = 
this.advised.getInterceptorsAndDynamicInterceptionAdvice 
(method, targetClass); 
if (chain.isEmpty()) 1 
/如 果 没 有 发 现任 何 拦截 器 那么 直接 调用 切 点 方法 
retVal = AopUtils.invokeJoinpointUsingReflection(target, method, 





args); 
}else { 

// 将 拦截 器 封装 在 ReflectiveMethodInvocation， 

/以 便于 使 用 其 proceed 进 行 链接 表 用 拦截 器 

invocation = new ReflectiveMethodInvocation(proxy, target, 
method, 

args, targetClass, chain); 

/执行 拦截 器 链 


retVal = invocation.proceed(); 


/返回 结果 

if (retVal != null && retVal == target && 
method.getReturnType(). IsInstance 

(proxy) && 


!'RawTargetAccess.class.isAssignableFrom(method.getDeclaringClass())) 1 
retVal = proxy; 
} 
return ret Val; 
} 
finally { 
if (target != null && !targetSource.isStatic()) { 
// Must have come from TargetSource. 
targetSource.releaseTarget(target); 
j 
if (setProxyContext) { 
// Restore old proxy. 
AopContext.setCurrentProxy(oldProxy); 


} 

上 面 的 函数 中 最 主要 的 工作 就 是 创建 了 一 个 拦截 器 链 ， 并 使 用 
ReflectiveMethodInvocation 类 进行 了 链 的 封 疾 ， 而 在 
ReflectiveMethodInvocation 类 的 proceed 方 法 中 实现 了 拦截 器 的 逐一 调 
用 ， 那 么 我 们 继续 来 探究 ， 在 proceed 方 法 中 是 怎么 实现 前 置 增强 在 目标 
方法 前 调用 后 置 增强 在 目标 方法 后 调用 的 逻辑 呢 ? 


if (this.currentInterceptorIndex == 





this.interceptorsAndDynamicMethodMatchers. 
public Object proceed() throws Throwable { 
Il 执行 完 所 有 增强 后 执行 切 点 方法 
size() - 1) { 


return invokeJoinpoint(); 
} 
1/ 获取 下 一 个 要 执行 的 拦截 器 


Object interceptorOrInterceptionAdvice = 


this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptorIn 
if (interceptorOrInterceptionAdvice instanceof 
InterceptorAndDynamicMethodMatcher) { 
/动态 匹配 ， 
InterceptorAndDynamicMethodMatcher dm = 
(InterceptorAndDynamicMethodMatcher) 
interceptorOrInterceptionAdvice; 
if (dm.methodMatcher.matches(this.method, this.targetClass, 
this.arguments)) 1 
return dm.interceptor.invoke(this); 
jelse { 
/不 匹配 则 不 执行 拦截 器 


return proceed(); 





} 
}else 1 

PE Bias» EL Reval FE eas, Lean: 
* ExposeInvocationInterceptor. 
* DelegatePerTargetObjectIntroductionInterceptor. 
* MethodBeforeAdvicelnterceptor 
* AspectJAroundAdvice, 
* AspectJAfterAdvice 
i 


/将 this 作 为 参数 传递 以 保证 当前 实例 中 调用 链 的 执行 
return ((MethodInterceptor) 
interceptorOrInterceptionAdvice).invoke(this); 
} 

} 

在 proceed 方 法 中 ， 或 许 代 码 逻 辑 并 没有 我 们 想象 得 那么 复杂 ， 
ReflectiveMethodInvocation 中 的 主要 职责 是 维护 了 链接 调用 的 计数 器 ， 
记录 着 当前 调用 链接 的 位 置 ， 以 便 链 可 以 有 序 地 进行 下 去 ， 那 么 在 这 个 
方法 中 并 没有 我 们 之 前 设想 的 维护 各 种 增强 的 顺序 ， 而 是 将 此 工作 委托 
给 了 各 个 增强 器 ， 使 各 个 增强 器 在 内 部 进行 逻辑 实现 。 

(2) CGLIB 使 用 示例 。 

CGLIB 是 一 个 强大 的 高 性 能 的 代码 生成 包 。 它 广泛 地 被 许多 AOP 的 
框架 使 用 ， 例 如 Spring AOP 和 dynaop， 为 他 们 提供 方法 的 
Interception (拦截 ) 。 最 流行 的 OR Mapping 工 具 Hibernate 也 使 用 CGLIB 
来 代理 单 端 single-ended (多 对 一 和 一 对 一 ) 关联 (对 集合 的 延迟 抓 取 是 
采用 其 他 机 制 实现 的 ) 。EasyMock 和 jMock 是 通过 使 用 模仿 (moke) 对 
象 来 测试 Java 代 码 的 包 。 它 们 都 通过 使 用 CGLIB 来 为 那些 没有 接口 的 类 
创建 模仿 (moke) 对 象 。 

CGLIB 包 的 底层 通过 使 用 一 个 小 而 快 的 字 节 码 处 理 框 架 ASM， 来 转 
换 字 节 码 并 生成 新 的 类 。 除 了 CGLIB 包 ， 脚 本 语言 例如 Groovy 和 
BeanShell， 也 是 使 用 ASM 来 生成 Java 的 字 节 码 。 当 然 不 鼓励 直接 使 用 
ASM， 因 为 它 要 求 你 必须 对 JVM 内 部 结构 包括 class 文 件 的 格式 和 指令 集 
都 很 熟悉 。 

我 们 先 快速 地 了 解 CGLIB 的 使 用 示例 。 


import java.lang.reflect. Method; 





import net.sf.cglib.proxy.Enhancer; 


import net.sf.cglib.proxy.MethodInterceptor; 


import net.sf.cglib.proxy.MethodProxy; 
public class EnhancerDemo { 
public static void main(String[] args) 1 
Enhancer enhancer = new Enhancer(); 
enhancer.setSuperclass(EnhancerDemo.class); 
enhancer.setCallback(new MethodInterceptorImpl()); 


EnhancerDemo demo = (EnhancerDemo) enhancer.create(); 
demo.test(); 


System.out.printIn(demo); 
} 
public void test() { 


System.out.printIn("EnhancerDemo test()"); 


} 


private static class MethodInterceptorImpl implements 


MethodInterceptor 1 


@Override 

public Object intercept(Object obj, Method method, Object[] args, 

MethodProxy proxy) throws Throwable 1 
System.err.printIn("Before invoke " + method); 
Object result = proxy.invokeSuper(obj, args); 
System.err.println(" After invoke" + method); 


return result; 


j 
运行 结果 如 下 : 


Before invoke public void EnhancerDemo.test() 


EnhancerDemo test() 
After invokepublic void EnhancerDemo.test() 
Before invoke public java.lang.String java.lang.Object.toString() 
Before invoke public native int java.lang.Object.hashCode() 
After invokepublic native int java.lang.Object.hashCode() 
After invokepublic java.lang.String java.lang.Object.toString() 
EnhancerDemo$$EnhancerByCGLIB$$bc9b2066@1621e42 
可 以 看 到 System.out.println(demo), demo 首先 调用 了 toString() 方 
法 ， 然 后 又 调用 了 hashCode， 生 成 的 对 象 为 
EnhancerDemo$$EnhancerByCGLIB$$bc9b2066 的 实例 ， 这 个 类 是 运行 
时 由 CGLIB 产 生 的 。 
完成 CGLIB 代 理 的 类 是 委托 给 Cglib2AopProxy 类 去 实现 的 ， 我 们 进 
入 这 个 类 一 探 完 竟 。 
按照 前 面 提供 的 示例 ， 我 们 容易 判断 出 来 ，Cglib2AopProxy 的 入 口 
应 该 是 在 getProxy， 也 就 是 说 在 Cglib2AopProxy 类 的 getProxy 方 法 中 实现 
了 Enhancer 的 创建 及 接口 封装 。 
public Object getProxy(ClassLoader classLoader) { 
if (logger.isDebugEnabled()) { 
logger.debug(" Creating CGLIB2 proxy: target source is " + 
this.advised. 
getTargetSource()); 
j 
try 1 
Class rootClass = this.advised.getTargetClass(); 
Assert.state(rootClass != null, "Target class must be available for 
creating 
a CGLIB proxy"); 


Class proxySuperClass = rootClass; 

if (ClassUtils.isCglibProxyClass(rootClass)) { 
proxySuperClass = rootClass.getSuperclass(); 
Class[] additionalInterfaces = rootClass.getInterfaces(); 
for (Class additionalInterface : additionalInterfaces) { 


this.advised.addInterface(additionalInterface); 


j 
/验证 Class 
validateClassIfNecessary(proxySuperClass); 
/创建 及 配置 Enhancer 
Enhancer enhancer = createEnhancer(); 
if (classLoader != null) { 
enhancer.setClassLoader(classLoader); 
if (classLoader instanceof SmartClassLoader && 
((SmartClassLoader) classLoader).isClassReloadable(proxy 
SuperClass)) 1 
enhancer.setUseCache(false); 


} 


enhancer.setSuperclass(proxySuperClass); 
enhancer.setStrategy(new 
UndeclaredThrowableStrategy(UndeclaredThrowable 


Exception.class)); 


enhancer.setInterfaces( AopProxyUtils.completeProxiedInterfaces(this.advisec 


enhancer.setInterceptDuringConstruction(false); 


BT Bas 
Callback[] callbacks = getCallbacks(rootClass); 
enhancer.setCallbacks(callbacks); 
enhancer.setCallbackFilter(new ProxyCallbackFilter( 
this.advised.getConfigurationOnlyCopy(), 
this.fixedInterceptorMap, 
this.fixedInterceptorOffset)); 
Class[] types = new Class[callbacks.length]; 
for (int x = 0; x < types.length; x++) { 
types[x] = callbacks[x].getClass(); 
} 
enhancer.setCallbackTypes(types); 
/生成 代理 类 以 及 创建 代理 
Object proxy; 
if (this.constructorArgs != null) { 
proxy = enhancer.create(this.constructorArgTypes, 


this.constructorArgs); 


} 
else { 
proxy = enhancer.create(); 
} 
return proxy; 
} 


catch (CodeGenerationException ex) { 
throw new AopConfigException("Could not generate CGLIB 


subclass of class [" + 
this.advised.getTargetClass() + "]: " + 


"Common causes of this problem include using a final class or a 
non-visible class", 
ex); 
j 
catch (IllegalArgumentException ex) 1 
throw new AopConfigException("Could not generate CGLIB 
subclass of class [" + 
this.advised.getTargetClass() + "]: " + 
"Common causes of this problem include using a final class or a 
non-visible class", 
ex); 
j 
catch (Exception ex) 1 
// TargetSource.getTarget() failed 
throw new AopConfigException(" Unexpected AOP exception", 


ex); 


以 上 函数 完整 地 前 述 了 一 个 创建 Spring 中 的 Enhancer 的 过 程 ， 读 者 
可 以 参考 Enhancer 的 文档 查看 每 个 步骤 的 含义 ， 这 里 最 重要 的 是 通过 
getCallbacks 方 法 设置 拦截 器 链 。 
private Callback[] getCallbacks(Class rootClass) throws Exception { 
/对 于 expose-proxy 属 性 的 处 理 


boolean exposeProxy = this.advised.isExposeProxy(); 





boolean isFrozen = this.advised.isFrozen(); 
boolean isStatic = this.advised.getTargetSource().isStatic(); 
/将 拦截 器 封装 在 DynamicAdvisedInterceptor 中 


Callback aopInterceptor = new 
DynamicAdvisedInterceptor(this.advised); 
// Choose a "straight to target" interceptor. (used for calls that are 
// unadvised but can return this). May be required to expose the 
proxy. 
Callback targetInterceptor; 
if (exposeProxy) { 
targetInterceptor = isStatic ? 
new StaticUnadvisedExposedInterceptor 
(this.advised.getTargetSource(). 
getTarget()) : 
new 
DynamicUnadvisedExposedInterceptor(this.advised.get l'argetSource()); 
jelse 1 
targetInterceptor = isStatic ? 
new StaticUnadvisedInterceptor(this.advised.getTargetSource(). 
getTarget()) : 
new 
DynamicUnadvisedInterceptor(this.advised.get l'argetSource()); 
j 
// Choose a "direct to target" dispatcher (used for 
// unadvised calls to static targets that cannot return this). 
Callback targetDispatcher - isStatic ? 
new StaticDispatcher(this.advised.getTargetSource().getTarget()) : 
new SerializableNoOp(); 
Callback[] mainCallbacks = new Callback[]{ 
/将 拦截 器 链 加 入 Callback 中 


aopInterceptor, 
targetInterceptor, // invoke target without considering advice, if 
optimized 
new SerializableNoOpd(), // no override for methods mapped to this 
targetDispatcher, this.advisedDispatcher, 
new EqualsInterceptor(this.advised), 
new HashCodelInterceptor(this.advised) 
H 
Callback[] callbacks; 
// If the target is a static one and the advice chain is frozen, 
// then we can make some optimisations by sending the AOP calls 
// direct to the target using the fixed chain for that method. 
if (isStatic && isFrozen) { 
Method[] methods = rootClass.getMethods(); 
Callback[] fixedCallbacks = new Callback[methods. length]; 
this.fixedInterceptorMap = new HashMap<String, Integer> 
(methods.length); 
// TODO: small memory optimisation here (can skip creation for 
// methods with no advice) 
for (int x = 0; x < methods.length; x++) { 
List<Object> chain = this.advised.getInterceptorsAndDynamic 
Interception 
Advice(methods[x], rootClass); 
fixedCallbacks[x] = new FixedChainStaticTargetInterceptor( 
chain, this.advised.getTargetSource().getTarget(), this.advised. 
getTargetClass()); 
this.fixedInterceptorMap.put(methods[x].toString(), x); 


} 
// Now copy both the callbacks from mainCallbacks 
// and fixedCallbacks into the callbacks array. 
callbacks = new Callback[mainCallbacks.length + 
fixedCallbacks.length]; 
System.arraycopy(mainCallbacks, 0, callbacks, 0, 
mainCallbacks.length); 
System.arraycopy(fixedCallbacks, 0, callbacks, 
mainCallbacks.length, 
fixedCallbacks.length); 
this.fixedInterceptorOffset = mainCallbacks.length; 
} 
else { 
callbacks = mainCallbacks; 
} 
return callbacks; 
} 
在 getCallback 中 Spring 考虑 了 很 多 情况 ， 但 是 对 于 我 们 来 说 ， 只 需 
要 理解 最 党 用 的 束 可 以 了 ， 比 如 将 advised 属 性 
DynamicAdvisedInterceptor 并 加 入 在 callbacks 中 ， 这 么 做 的 目的 是 什么 
呢 ， 如 何 调用 呢 ? 在 前 面 的 示例 中 ， 我 们 CGLIB 中 对 于 方法 的 
拦截 是 通过 将 自 定 义 的 拦截 器 (实现 MethodInterceptor 接 口 ) 加 入 
Callback 中 并 在 调用 代理 时 直接 激活 拦截 妖 中 的 intercept 方法 来 实现 
的 ， 那 么 在 getCallback 中 正 是 实现 了 这 样 一 个 目的 ，Dynamic 
AdvisedInterceptor 继 承 目 MethodInterceptor， 加 入 Callback 中 后 ， 在 再 次 
调用 代理 时 会 直接 调用 DynamicAdvisedInterceptor 中 的 intercept 方 法 ， 由 
此 推 亲 ， 对 于 CGLIB 方 式 实现 的 代理 ， 其 核心 逻辑 必然 在 





DynamicAdvisedInterceptor 中 的 intercept 中 。 
public Object intercept(Object proxy, Method method, Object[] args, 
MethodProxy methodProxy) 
throws Throwable { 
Object oldProxy = null; 
boolean setProxyContext = false; 
Class targetClass = null; 
Object target = null; 
try { 
if (this.advised.exposeProxy) { 
// Make invocation available if necessary. 
oldProxy = AopContext.setCurrentProxy(proxy); 
setProxyContext = true; 
} 
target = getTarget(); 
if (target != null) { 
targetClass = target.getClass(); 
} 
/获取 拦截 器 链 
List<Object> chain = 
this.advised.getInterceptorsAndDynamicInterceptionAdvice 
(method, targetClass); 
Object retVal; 
if (chain.isEmpty() && Modifier.isPublic(method.getModifiers())) 


/如 果 拦 截 器 链 为 空 则 直接 激活 原 方法 


retVal = methodProxy.invoke(target, args); 


yelse 1 
/进入 链 
retVal = new CglibMethodInvocation(proxy, target, method, 


args, 
targetClass, chain, methodProxy).proceed(); 
} 
retVal = massageReturnT ypelfNecessary(proxy, target, method, 
retVal); 
return retVal; 
} 
finally { 


if (target != null) { 
releaseTarget(target); 

} 

if (setProxyContext) { 
// Restore old proxy. 
AopContext.setCurrentProxy(oldProxy); 


} 

上 上述 的 实现 与 JDK 方 式 实现 代理 中 的 invoke 方 法 大 同 小 异 ， 都 是 首 
先 构造 链 ， 然 后 封装 此 链 进行 串 联 调用 ， 稍 有 些 区 别 束 是 在 JDK 中 直接 
构造 ReflectiveMethodInvocation， 而 在 cglib 中 使 用 
CglibMethodInvocation. CglibMethodInvocation 27K E 
ReflectiveMethodInvocation， 但 是 proceed 方 法 并 没有 重 写 。 





7.4 静态 AOP ZN IP 


加 载 时 织 入 〈Load-Time Weaving, LTW) 指 的 是 在 虚拟 机 载 入 字 
节 码 文件 时 动态 织 入 AspectU 切 面 。Spring 框 架 的 值 添加 为 AspecU LTW 
在 动态 织 入 过 程 中 提供 了 更 细 料 上 度 的 控制 。 使 用 Java (5+) 的 代理 能 使 
用 一 个 叫 “Vanilla* 的 AspectJ LTW， 这 需要 在 启动 JVM 的 时 候 将 某 个 
JVM 参 数 设置 为 开 。 这 种 JVM 范 围 的 设置 在 一 些 情况 下 或 许 不 错 ， 但 通 
常情 况 下 显得 有 些 粗 颗粒 。 而 用 Spring 的 LTW 能 让 你 在 per-ClassLoader 
的 基础 上 打开 LTW， 这 显然 更 加 细 粒 度 并 且 对 “ 单 JVM 多 应 用 ”的 环境 更 
上 其 意义 “例如 在 一 个 典型 应 用 服务 器 环境 中 ) 。 另 外 ， 在 某 些 环境 下 ， 
这 能 让 你 使 用 LTW 而 不 对 应 用 服务 器 的 启动 脚本 做 任何 改动 ， 不 然则 需 
要 添加 -javaagent:path/to/aspectjweaver.jar 或 者 (以 下 将 会 提 及 的 ) - 
javaagent:path/to/Spring-agent.jar。 开 发 人 员 只 需 简 单 修改 应 用 上 下 文 的 
一 个 或 几 个 文件 就 能 使 用 LTW， 而 不 需 依靠 那些 管理 者 部 团 配 置 ， 比 如 
启动 脚本 的 系统 管理 员 。 

我 们 还 是 以 之 前 的 AOP 示例 为 基础 ， 如 果 想 从 动态 代理 的 方式 改 
成 静态 代理 的 方式 需要 做 如 下 改动 。 

(1) Spring 全 局 配置 文件 的 修改 ， 加 入 LWT 开 关 。 


<?xml version="1.0" encoding="UTF-8"?> 

















«beans xmlns="http:/www.Springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:aop="http://www.Springframework.org/schema/aop" 


xmlns:context="http://www.Springframework.org/schema/context" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www.Springframework.org/schema/beans/Spring- 
beans-3.0.xsd 
http://www.Springframework.org/schema/aop 


http://www.Springframework.org/schema/aop/Spring-aop -3.0.xsd 


http://www.Springframework.org/schema/context http: 
//www.Springframework.org/schema/context/Spring-context- 
3.0.xsd 
<aop:aspectj-autoproxy /> 
<bean id="test" class="test.TestBean"/> 
<bean class="test.AspectJTest"/> 
<context:load-time-weaver /> 
</beans> 
(2) 加 入 aop.xml。 在 class 目 录 下 的 META-INF (没有 则 自己 建 
XE) 文件 夹 下 建立 aop.xml， 内 容 如 下 : 
<!DOCTYPE aspect} PUBLIC "-//AspectJ//DTD//EN" 
"http://www.eclipse.org/aspectj/dtd/aspectj.dtd"> 
<aspectj> 
<weaver> 
<!-- only weave classes in our application-specific packages --> 
<include within="test.*" /> 
</weaver> 
<aspects> 
<!-- weave in just this aspect --> 
«aspect name- "test. AspectJTest" /> 
</aspects> 
</aspectj> 
主要 是 告诉 AspectJ 需 要 对 哪个 包 进 行 织 入 ， 并 使 用 哪些 增强 器 。 
(3) 加 入 局 动 参数 。 如 果 是 在 Eclipse 中 启动 的 话 需 要 加 上 启动 参 
数 ， 如 图 7-3 所 示 。 





© Main 0% Arguments » BA JRE Classpath | $^ Source | P Environment) © Common | Tracepoint 


Program arguments: 


Varjables... 


VM arguments: 


-javaagentze:\org.springframework.instrumentjar 


Variables... 


Working directory: 
© Default: ${workspace_locorg.springtramework.context} 


Other: 


图 7-3 eclipsefii H AspectJ HY Ac E. 


(45 测试 。 
public static void main(String[] args) { 
ApplicationContext bf = new 
ClassPathXmlApplicationContext("aspectTest.xml"); 
IITestBean bean-(IITestBean) bf.getBean( test"); 


bean.testBeanM(); 
} 
测试 结果 与 动态 AOP 并 无 差别 ， 打 印 出 结果 : 
beforeTest 
test 
afterTest 


7.5 创建 AOP 静 态 代 理 


AOP 的 静态 代理 主要 是 在 虚拟 机 局 动 时 通过 改变 目标 对 象 字 节 码 
的 方式 来 完成 对 目标 对 象 的 增强 ， 它 与 动态 代理 相 比 具有 更 高 的 效率 ， 








因为 在 动态 代理 调用 的 过 程 中 ， 还 需要 一 个 动态 创建 代理 类 并 代理 目标 
对 象 的 步 又 ， 而 静态 代理 则 是 在 局 动 时 便 完 成 了 字 市 码 增 强 ， 当 系统 再 
次 调用 目标 类 时 与 调用 正音 的 类 并 无 差别 ， 所 以 在 效率 上 会 相对 高 些 。 


7.5.1 Instrumentation 使 用 
Java 在 1.5 引 入 java.lang.instrument， 你 可 以 由 此 实现 一 个 Java 
agent, MITH agent 来 修改 类 的 字 节 码 即 改变 一 个 类 。 本 节 会 通过 Java 


Instrument 实 现 一 个 简单 的 profiler。 当 然 instrument 并 不 限 
instrument 它 可 以 做 很 多 事情 ， 它 类 似 一 种 更 低级 、 更 松 耦 合 的 AOP， 

可 以 从 底层 来 改变 一 个 类 的 行为 。 你 可 以 由 此 产生 无 限 的 遐想 。 接 下 来 
要 做 的 事情 ， 就 是 计算 一 个 方法 所 花 的 时 间 ， 通 第 我 们 会 在 代码 中 按 以 
下 方式 编号 。 

在 方法 开头 加 入 long stime = System.nanoTime(); 在 方法 结尾 通过 
System.nanoTime(O-stime 得 出 方法 所 花 时 间 。 你 不 得 不 在 想 监 控 的 每 个 
方法 中 写 入 重复 的 代码 ， 好 一 点 的 情况 ， 你 可 以 用 AOP 来 干 这 事 ， 但 总 

是 感 党 有 点 别扭 ， 这 种 profiler 的 代码 还 是 要 打包 在 你 的 项 目 中 ，Java 
Instrument 使 得 这 一 切 更 干净 。 
(1) 写 ClassFileTransformer 类 。 


package org.toy; 














import java.lang.instrument.ClassFileTransformer; 
import java.lang.instrument.IllegalClassFormatException; 
import java.security.ProtectionDomain; 

import javassist. CannotCompileException; 

import javassist.ClassPool; 

import javassist. CtBehavior; 

import javassist.CtClass; 


import javassist. NotFoundException; 


import javassist.expr.ExprEditor; 
import javassist.expr.MethodCall; 
public class PerfMonXformer implements ClassFileTransformer { 
public byte[] transform(ClassLoader loader, String className, 
Class<?> classBeingRedefined, ProtectionDomain protectionDomain, 
byte[] classfileBuffer) throws IllegalClassFormatException { 

byte[] transformed - null; 

System.out.println(" Transforming " + className); 

ClassPool pool = ClassPool.getDefault(); 

CtClass cl = null; 


try 1 
cl = pool.makeClass(new java.io.ByteArrayInputStream( 
classfileBuffer)); 


if (cl.isInterface() —- false) { 
CtBehavior[] methods = cl.getDeclaredBehaviors(); 
for (int i = 0; i € methods.length; i++) { 
if (methods[i].isEmpty() == false) 1 
/修改 method 字 节 码 
doMethod(methods[i |); 


j 
transformed = cl.toBytecode(); 
j 
} catch (Exception e) { 
System.err.println("Could not instrument " + className 
+", exception : " + e.getMessage()); 
} finally { 


if (cl != null) { 
cl.detach(); 


j 
return transformed; 
j 
private void doMethod(CtBehavior method) throws 
NotFoundException, 
CannotCompileException 1 
method.insertBefore("long stime = System.nanoTime();"); 
method.insertAfter("System.out.println(/"leave 
"+method.getName()+" and 


time:/"+(System.nanoTime()-stime));"); 


} 
(2) 编写 agent 类 。 
package org.toy; 
import java.lang.instrument.Instrumentation; 
import java.lang.instrument.ClassFileTransformer; 
public class PerfMonA gent { 
Static private Instrumentation inst = null; 
[RK 
* This method is called before the application’s main-method is 
called, 
* when this agent is specified to the Java VM. 


米 米 / 


public static void premain(String agentArgs, Instrumentation _inst) { 


System.out.println("PerfMonAgent.premain() was called."); 

// Initialize the static variables we use to track information. 

inst = inst; 

// Set up the class-file transformer. 

ClassFileTransformer trans = new PerfMonXformer(); 

System.out.println(" Adding a PerfMonXformer instance to the 
JVM."); 


inst.addTransformer(trans); 


上 面 两 个 类 束 是 agent 的 核心 了 ，JVM 局 动 时 在 应 用 加 载 前 会 调用 
PerfMonAgent.premain， 然 后 PerfMonAgent.premain 中 实例 化 了 一 个 定 
制 的 ClassFileTransforme， 即 PerfMonXformer 并 通过 
inst.addTransformer(trans) 把 PerfMonXformer 的 实例 加 入 Instrumentation 实 
例 〈 由 JVM 传 入 ) ， 这 束 使 得 应 用 中 的 类 加 载 时 ， 
PerfMonXformer.transform 都 会 被 调用 ， 你 在 此 方法 中 可 以 改变 加 载 的 
类 。 真 的 有 点 神奇 ， 为 了 改变 类 的 字 节 但 ， 我 使 用 了 JBoss 的 Javassist， 
虽然 你 不 一 定 要 这 么 用 ， 但 JBoss 的 Javassist 真 的 很 强大 ， 能 让 你 很 容易 
地 改变 类 的 字 节 码 。 在 上 面 的 方法 中 我 通过 改变 类 的 字 市 码 ， 在 每 个 类 
的 方法 入 口中 加 入 了 long stime = System.nanoTime()， 在 方法 的 出 口 加 
AT: 


System.out.println("methodClassName.methodName:"+ 











(System.nanoTime()-stime)); 
(3) 打包 agent。 
对 于 agent 的 打包 ， 有 点 讲 完 。 
JAR 的 META-INF/MANIFEST.MF 加 入 Premain-Class: xx, xx f Jis 
境 中 就 是 我 们 的 agent 类 ， 即 org.toy.PerfMonAgent。 





如 果 你 的 agent 类 引入 别 的 包 ， 需 使 用 Boot-Class-Path: xx，xx 在 此 
语 境 中 就 是 上 面 提 到 的 JBoss javassit， 
B /home/pwlazy/.m2/repository/javassist/javassist/3.8.0 .GA/ javassist- 
3.8.0.GA. jar. 
下 面 附 上 Maven 的 POM。 
[xhtmljview plaincopyprint? 
<project xmlns="http://maven.apache.org/POM/4.0.0" 
xmins:xsi="http://www.w3.org/2001/ 
XMLSchema-instance" 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven- 
v4_0_0.xsd"> 
<modelVersion>4.0.0</modelVersion> 
<groupId>org.toy</groupId> 
<artifactId>toy-inst</artifactId> 
<packaging>jar</packaging> 
<version>1.0-SNAPSHOT</version> 
<name>toy-inst</name> 
<url>http://maven.apache.org</url> 
<dependencies> 
<dependency> 
<groupId>javassist</groupId> 
<artifactId>javassist</artifactId> 
<version>3.8.0.GA</version> 
</dependency> 
<dependency> 


<groupId>junit</groupId> 


<artifactId>junit</artifactId> 
<version>3.8.1</version> 
<scope>test</scope> 
</dependency> 
</dependencies> 
<build> 
<plugins> 
<plugin> 
<groupld>org.apache.maven.plugins</groupld> 
<artifactId>maven-jar-plugin</artifactId> 
<version>2.2</version> 
<configuration> 
<archive> 
<manifestEntries> 
<Premain-Class>org.toy.PerfMonA gent</Premain- 
Class> 
<Boot-Class- 
Path>/home/pwlazy/.m2/repository/javassist/javassist/3.8.0.GA/ 
javassist-3.8.0.GA.jar</Boot-Class-Path> 
</manifestEntries> 
</archive> 
</configuration> 
</plugin> 
<plugin> 
<artifactiId>maven-compiler-plugin </artifactId > 
<configuration> 


<source> 1.6 </source > 


<target> 1.6 </target> 
</configuration> 
</plugin> 
</plugins> 
</build> 
</project> 
(4) 打包 应 用 。 
package org.toy; 
public class App { 
public static void main(String[] args) { 
new App().test(); 
} 
public void test() 1 
System.out.printIn("Hello World!!"); 


j 

Java 选 项 中 有 -javaagent:xX， 其 中 xx 就 是 你 的 agent JAR，Java 通 过 
此 选项 加 载 agent， 由 agent 来 监控 classpath 下 的 应 用 。 

最 后 的 执行 结 

PerfMonAgent.premain() was called. 

Adding a PerfMonXformer instance to the JVM. 

Transforming org/toy/App 

Hello World!! 

java.io.PrintStream.println:314216 

org.toy.App.test:540082 

Transforming java/lang/Shutdown 


Transforming java/lang/Shutdown$Lock 


java.lang.Shutdown.runHooks:29124 
java.lang.Shutdown.sequence: 132768 
由 执行 结果 可 以 看 出 ， 执 行 顺序 以 及 通过 改变 org.toy.App 的 字 节 
码 加 入 监控 代码 确实 生效 了 。 你 也 可 以 发 现 ， 通 过 Instrment 实 现 agent 使 
得 监控 代码 和 应 用 代码 完全 隔离 了 。 
通过 之 前 的 两 个 小 示例 我 们 似乎 已 经 有 所 体会 ， 在 Spring 中 的 静态 
AOP 直接 使 用 了 AspectJ 提 供 的 方法 ， 而 AspectJ] 又 是 在 Instrument 基 础 上 
进行 的 封装 。 融 以 上 面 的 例子 来 看 ， 至 少 在 AspecU 中 会 有 如 下 功能 
(1) 读 取 META-INF/aop.xml。 
(2) 将 aop.xml 中 定义 的 增强 器 通过 自 定义 的 ClassFileTransformer 
织 入 对 应 的 类 中 。 
当然 这 都 是 AspectU 上 所 做 的 事情 ， 并 不 在 我 们 讨论 的 范畴 ，Spring 是 
直接 使 用 AspecUJ， 也 就 是 将 动态 代理 的 任务 直接 委托 给 了 AspectJ， 那 
么 ，Spring 怎么 散 入 AspectJ 的 呢 ? 同 样 我 们 还 是 从 配置 文件 入 手 。 


7.5.2 目 定 义 标签 


在 Spring 中 如 果 需 要 使 用 Aspect 的 功能 ， ap neers 
配置 文件 中 加 入 配置 «context:load-time-weaver/». RARI Z AITE 
EA A xe XU 44 28 Ta) ASU EY DA HE, S| Aspect BELA, Ff fex E, 可 
以 通过 查找 load-time-weaver 来 找到 对 应 的 自 定义 命名 处 理 类 。 
通过 Eclipse 提供 的 字符 串 搜 索 功 能 ， 我 们 找到 了 
ContextrNamespaceHandler， 在 其 中 有 这 样 一 段 函数 。 
public void init() { 
registerBeanDefinitionParser("property-placeholder", new 
Property Placeholder 
BeanDefinitionParser()); 


registerBeanDefinitionParser("property-override", new 


PropertyOverrideBean 

DefinitionParser()); 

registerBeanDefinitionParser("annotation-config", new 
AnnotationConfigBean 

DefinitionParser()); 

registerBeanDefinitionParser("component-scan", new 
ComponentScanBeanDefinition 

Parser()); 

registerBeanDefinitionParser("load-time-weaver", new 
LoadTimeWeaverBeanDefinition 

Parser()); 

registerBeanDefinitionParser("Spring-configured", new 
SpringConfiguredBeanDefinition 

Parser()); 

registerBeanDefinitionParser("mbean-export", new 
MBeanExportBeanDefinitionParser()); 

registerBeanDefinitionParser("mbean-server", new 
MBeanServerBeanDefinitionParser()); 

j 
继续 跟 进 LoadTimeWeaverBeanDefinitionParser， 作 为 

BeanDefinitionParser 接 口 的 实现 类 ， 他 的 核心 逻辑 是 从 parse 函 数 开始 
的 ， 而 经 过 父 类 的 封装 ，LoadTimeWeaverBeanDefinitionParser 类 的 核心 
实现 被 转移 到 了 doParse 函 数 中 ， 如 下 : 


protected void doParse(Element element, ParserContext parserContext, 





BeanDefinition 
Builder builder) { 
builder.setRole(BeanDefinition., ROLE_INFRASTRUCTURE); 


if 
(isAspectJWeavingEnabled(element.getAttribute(ASPECTJ WEAVING AT 
parserContext)) 1 
RootBeanDefinition weavingEnablerDef = new 
RootBeanDefinition(); 
// ASPECTJ WEAVING ENABLER, CLASS NAME = 
// 


"org. Springframework.context.weaving.AspectJWeavingEnabler"; 


weavingEnablerDef.setBeanClassName(ASPECTJ WEAVING ENABLER 


parserContext.getReaderContext().registerWithGeneratedName(weavingEnab 
if 
(isBeanConfigurerAspectEnabled(parserContext.getReaderContext().getBean 
ClassLoader())) 1 
new SpringConfiguredBeanDefinitionParser().parse(element, 
parserContext); 


} 


} 

FESR ZHU TE ot PTB ASA OP tH Wt x TE 7) HT AC El <aop:aspectj-autoproxy 
/> 中 已 经 提 到 了 上 自 定义 配置 的 解析 流程 ， 对 于 <aop:aspectj-autoproxy/> 的 
解析 无 非 是 以 标签 作为 标志 ， 进 而 进行 相关 处 理 类 的 注册 ， 那 么 对 于 自 
定义 标签 <context:load-time-weaver /> 其 实 是 起 到 了 同样 的 作用 。 

上 面 函 数 的 核心 作用 其 实 就 是 注册 一 个 对 于 ApectJ 处 理 的 类 
org.Springframework.context. Weaving.AspectJWeavingEnabler， 它 的 注册 
流程 总 结 起 来 如 下 。 


(1) 是否 开局 AspectJ。 

之 前 虽然 反复 提 到 了 在 配置 文件 中 加 入 了 <context:load-time- 
weaver/> 便 相当 于 加 入 了 AspectJ 开 关 。 但 是 ， 并 不 是 配置 了 这 个 标签 残 
意味 着 开启 了 AspectJ 功 能 ， 这 个 标签 中 还 有 一 个 属性 aspectj-weaving,， 
这 个 属性 有 3 个 备 选 值 ，on、off 和 autodetect， 默 认为 autodetect， 也 就 是 
说 ， 如 果 我 们 只 是 使 用 了 <context:load-time-weaver >， 那 么 Spring 会 帮 
助 我 们 检测 是 否 可 以 使 用 AspectJ 功 能 ， 而 检测 的 依据 便 是 文件 META- 
INEF/aop.xml 是 否 存 在 ， 看 看 在 Spring 中 的 实现 方式 。 

protected boolean isAspectJWeavingEnabled(String value, 





ParserContext parserContext) { 
if ("on".equals(value)) { 
return true; 
} 
else if ("off".equals(value)) 1 
return false; 
j 
else { 
/上 自动 检测 
ClassLoader cl = 
parserContext.getReaderContext().getResourceLoader(). 
getClassLoader(); 
return 
(cl.getResource(AspectJWeavingEnabler.ASPECTJ AOP XML RESOURC 
!- null); 


(2) 将 


org.Springframework.context.weaving.AspectJWeavingEnabler 封装 在 
BeanDefinition 中 注册 。 
当 通 过 AspectJ 功 能 验证 后 便 可 以 进行 AspectJWeavingEnabler 的 注册 
了 ， 注 册 的 方式 很 简单 ， 无 非 是 将 类 路 径 注册 在 新 初始 化 的 
RootBeanDefinition 中 ， 在 RootBeanDefinition 的 获取 时 会 转换 成 对 应 的 
Class。 
尽管 在 init 方法 中 注册 了 AspectJWeavingEnabler， 但 是 对 于 标签 本 
二 Spring 也 会 以 bean 的 形式 保存 ， 也 就 是 当 Spring 解 析 到 <context:load- 
time-weaver > 标签 的 时 候 也 会 产生 一 个 bean， 而 这 个 bean 中 的 信息 是 什 
么 呢 ? 
在 LoadTimeWeaverBeanDefinitionParser 类 中 有 这 样 的 函数 : 
@Override 
protected String getBeanClassName(Element element) { 
if (element.hasAttribute(WEAVER, CLASS ATTRIBUTE)) { 
return element.getAttribute(WEAVER, CLASS ATTRIBUTE); 
} 
return DEFAULT LOAD TIME WEAVER CLASS NAME; 








@Override 
protected String resolveld(Element element, AbstractBeanDefinition 
definition, 
ParserContext parserContext) { 
return 
ConfigurableApplicationContext.LOAD TIME WEAVER BEAN NAME; 
j 
其 中 ， 可 以 看 到 : 
WEAVER_CLASS_ATTRIBUTE="weaver-class" 


DEFAULT LOAD TIME WEAVER CLASS NAME = 

"org. Springframework.context.weaving.DefaultContextLoadTimeWeave 

ConfigurableApplicationContext.LOAD_TIME_WEAVER_BEAN_NAI 

TRAE VI EB f SER BZD np AEDT, Spring FE cE I) H EM one 
<context:load-time-weaver> 后 会 产生 一 个 bean， 而 这 个 bean 的 id 为 
loadTimeWeaver，class 为 org.Springframework.context.weaving. 
DefaultContextLoadTimeWeaver， 也 就 是 完成 了 
DefaultContextLoadTimeWeaver 类 的 注册 。 

完成 了 以 上 的 注册 功能 后 ， 并 不 意味 这 在 Spring 中 就 可 以 使 用 
Aspect) 了， 因为 我 们 还 有 一 个 很 重要 的 步骤 忽略 了 ， 束 是 
LoadTimeWeaverAwareProcessor 的 注册 。 在 AbstractApplicationContext 
中 的 prepareBeanFactory 函 数 中 有 这 样 一 段 代 码 : 

// 增 加 对 AspectJ 的 支持 

if 
(beanFactory.containsBean(LOAD TIME WEAVER BEAN NAME)) 1 
(beanFactory)); 





beanFactory.addBeanPostProcessor(new 
LoadTimeWeaverA wareProcessor 

// Set a temporary ClassLoader for type matching. 

beanFactory.setl'empClassLoader(new 
ContextTypeMatchClassLoader (beanFactory. 

getBeanClassLoader())); 

j 
在 AbstractApplicationContext 中 的 prepareBeanFactory 函数 是 在 容 

器 初始 化 时 候 调 用 的 ， 也 就 是 说 只 有 注册 了 
LoadTimeWeaverAwareProcessor 才 会 激活 整个 AspectJ 的 功能 。 


7.5.3 2H X 

当 我 们 完成 了 所 有 的 Aspect) 的 准备 工作 后 便 可 以 进行 织 入 分 析 
了 ， 首 先 还 是 从 LoadTimeWeaverAwareProcessor 开 始 。 

LoadTimeWeaverAwareProcessor 实 现 BeanPostProcessor 方 法 ， 那 么 
对 于 BeanPostProcessor 接 口 来 讲 ，postProcessBeforeInitialization 与 
postProcessAfterInitialization 有 着 其 特殊 意义 ， 也 就 是 说 在 所 有 bean 的 初 
始 化 之 前 与 之 后 都 会 分 别 调用 对 应 的 方法 ， 那 么 在 
LoadTimeWeaverA wareProcessor'¥ [‘JpostProcessBeforelnitialization 函数 
中 完成 了 什么 样 的 逻辑 呢 ? 


public Object postProcessBeforeInitialization(Object bean, String 








beanName) throws 
BeansException { 
if (bean instanceof LoadTimeWeaverAware) { 

LoadTimeWeaver ltw = this.loadTimeWeaver; 

让 (ltw == null) { 
Assert.state(this.beanFactory != null, 
"BeanFactory required if no LoadTimeWeaver explicitly 
specified"); 
ltw = this.beanFactory.getBean( 


ConfigurableApplicationContext.LOAD_TIME_WEAVER_BEAN_NAME, 
LoadTimeWeaver.class); 


} 


((LoadTimeWeaverA ware) bean).setLoadTimeWeaver(ltw); 


} 


return bean; 


} 

我 们 综合 之 前 讲解 的 所 有 信息 ， 将 所 有 相关 信息 串联 起 来 一 起 分 析 
这 个 函数 。 

在 LoadTimeWeaverAwareProcessor 中 的 
postProcessBeforeInitialization 函 数 中 ， 因 为 最 开始 的 让 判 断 注 定 这 个 后 处 
理 器 只 对 LoadTimeWeaverAware 类 型 的 bean 起 作用 ， 而 纵 观 所 有 的 
bean， 实 现 LoadTimeWeaver 接 口 的 类 只 有 AspectJWeavingEnabler。 

HÆ Spring i5 H] AspecUWeavingEnablerl], this.loadTimeWeaver ý 
未 被 初始 化 ， 那 么 ， 会 直接 调用 beanFactory.getBean 方 法 获取 对 应 的 
DefaultContextLoadTimeWeaver 类 型 的 bean， 并 将 其 设置 为 
AspectJWeavingEnabler 类 型 bean 的 loadTimeWeaver 属 性 中 。 当 然 
AspectJWeavingEnabler 同 样 实现 了 BeanClassLoaderAware 以 及 Ordered 接 
口 ， 实 现 BeanClassLoaderAware 接 口 保 证 了 在 bean 初 始 化 的 时 候 调 用 
AbstractAutowireCapableBeanFactory 的 invokeAwareMethods 的 时 候 将 
beanClassLoader 赋 值 给 当前 类 。 而 实现 Ordered 接 口 则 保证 在 实例 化 bean 
时 当前 bean 会 被 最 先 初 始 化 。 

而 DefaultContextLoadTimeWeaver 类 又 同时 实现 了 
LoadTimeWeaver、BeanClassLoaderAware 以 及 DisposableBean。 其 中 
DisposableBean 接 口 保证 在 bean 销 毁 时 会 调用 destroy 方 法 进行 bean 的 清 
理 ， 而 BeanClassLoaderAware 接口 则 保证 在 bean 的 初始 化 调用 
AbstractAutowireCapable BeanFactory 的 invokeAwareMethods 时 调用 
setBeanClassLoader 方 法 。 

public void setBeanClassLoader(ClassLoader classLoader) { 

LoadTimeWeaver serverSpecificLoadTimeWeaver = 
createServerSpecificLoadTimeWeaver 
(classLoader); 


if (serverSpecificLoadTimeWeaver != null) { 


if (logger.isInfoEnabled()) { 
logger.info(" Determined server-specific load-time weaver: " + 
serverSpecificLoadTimeWeaver.getClass().getName()); 
j 
this.loadTimeWeaver = serverSpecificLoadTimeWeaver; 
else if 
(InstrumentationLoadTimeWeaver.isInstrumentationA vailable()) 1 
/检查 当前 虚拟 机 中 的 Instrumentation 实 例 是 含 可 用 
logger.info("Found Spring's JVM agent for instrumentation"); 
this.loadTimeWeaver = new 
InstrumentationLoadTimeWeaver(classLoader); 
}else { 
try { 
this.loadTimeWeaver = new 
ReflectiveLoadTimeWeaver(classLoader); 
logger.info("Using a reflective load-time weaver for class 
loader: " + 
this.loadTimeWeaver. getInstrumentableClassLoader(). 
getClass().getName()); 
} 
catch (IllegalStateException ex) { 
throw new IllegalStateException(ex.getMessage() + " Specify a 
custom 
LoadTimeWeaver or start your " * 
"Java virtual machine with Spring's agent: -javaagent:org. 


Springframework.instrument.jar"); 


} 

上 面 的 函数 中 有 一 句 很 容易 被 忽略 但 是 很 关键 的 代码 : 

this.loadTimeWeaver = new 
InstrumentationLoadTimeWeaver(classLoader); 

这 名 代码 不 仅仅 是 实例 化 了 一 个 InstrumentationLoadTimeWeaver 类 
型 的 实例 ， 而 且 在 实例 化 过 程 中 还 做 了 一 些 额 外 的 操作 。 

在 实例 化 的 过 程 中 会 对 当前 的 this.instrumentation 属 性 进行 初始 化 ， 
而 初始 化 的 代码 如 下 : this.instrumentation = getInstrumentation0， 也 就 
是 说 在 InstrumentationLoadTimeWeaver 实 例 化 后 其 属性 Instrumentation 已 
经 被 初始 化 为 代表 着 当前 虚拟 机 的 实例 了 。 丝 合 我 们 讲 过 的 例子 ， 对 于 
注册 转换 器 ， 如 addTransformer 函 数 等 ， 便 可 以 直接 使 用 此 属性 进行 操 
emer 

也 就 是 经 过 以 上 程序 的 处 理 后 ， 在 Spring 中 的 bean 之 间 的 关系 如 
T: 

AspectJWeavingEnabler 类 型 的 bean 中 的 loadTimeWeaver 属性 被 初 
始 化 为 Default ContextLoadTimeWeaver 类 型 的 bean:; 

DefaultContextLoadTimeWeaver 类 型 的 bean 中 的 loadTimeWeaver 
属性 被 初始 化 为 InstrumentationLoadTimeWeaver。 

因为 AspectJWeavingEnabler 类 同样 实现 了 
BeanFactoryPostProcessor， 所 以 当 所 有 bean 解 析 结 束 后 会 调用 其 
postProcessBeanFactory 方 法 。 

public void postProcessBeanFactory(ConfigurableListableBeanFactory 
beanFactory) throws 

BeansException { 


enableAspectJWeaving(this.loadTimeWeaver, this.beanClassLoader); 


public static void enableAspectJWeaving(LoadTimeWeaver 
weaverToUse, ClassLoader 
beanClassLoader) { 
if (weaverToUse == null) { 
/此 时 已 经 被 初始 化 为 DefaultContextLoadTimeWeaver 
if (InstrumentationLoadTimeWeaver.isInstrumentationAvailable()) { 
weaverToUse = new 
InstrumentationLoadTimeWeaver(beanClassLoader); 
} 
else { 
throw new IllegalStateException("No LoadTimeWeaver 
available"); 
} 
} 
/使 用 DefaultContextLoadTimeWeaver 类 型 的 bean 中 的 
loadTimeWeaver 属 性 注册 转换 器 
weaverToUse.addTransformer(new 
AspectJClassBypassingClassFileTransformer( 
new ClassPreProcessorAgentA dapter())); 
j 
private static class AspectJClassBypassingClassFileTransformer 
implements Class 
FileTransformer { 
private final ClassFileTransformer delegate; 
public 
AspectJClassBypassingClassFileTransformer(ClassFileTransformer delegate) 
{ 


this.delegate = delegate; 
} 
public byte[] transform(ClassLoader loader, String className, Class<?> 
classBeingRedefined, 
ProtectionDomain protectionDomain, byte[] classfileBuffer) throws 
IllegalClassFormatException { 
if (className.startsWith("org.aspectj") || className.startsWith 
("org/aspectj")) 1 
return classfileBuffer; 
j 
/委托 给 AspectJ 代 理 继续 处 理 
return this.delegate.transform(loader, className, 
classBeingRedefined, 
protectionDomain, classfileBuffer); 
} 
} 
AspectJClassBypassingClassFileTransformer 的 作用 仅仅 是 告诉 
AspectJ 以 org.aspect 开头 的 或 者 org/aspectj 开头 的 类 不 进行 处 理 。 





Bem 类 XE B: JDBC 


JDBC (Java Data Base Connectivity，Java 数 据 库 连 接 ) 是 一 种 用 于 
执行 SQL 语句 的 Java API， 可 以 为 多 种 关系 数据 库 提 供 统一 访问 ， 它 由 
一 组 用 Java 语 言 编 写 的 类 和 接口 组 成 。JDBC 为 数据 库 开发 人 员 提 供 了 
一 个 标准 的 API， 据 此 可 以 构建 更 高 级 的 工具 和 接口 ， 使 数据 库 开 发 人 
员 能 够 用 纯 Java API 编 写 数 据 库 应 用 程序 ， 并 且 可 跨 平 台 运 行 ， 并 且 不 
受 数 据 库 供应 商 的 限制 。 

JDBC 连 接 数 据 库 的 流程 及 其 原理 如 下 。 

(1) 在 开发 环境 中 加 载 指定 数据 库 的 驱动 程序 。 接 下 来 的 实验 
中 ， 使 用 的 数据 库 是 MySQL， 所 以 需要 去 下 载 MySQL 文 持 JDBC KIK 
动 程序 〈 最 新 的 版 本 是 mysql-connector-java-5.1.18-bin.jar) ， 将 下 载 得 
到 的 张 动 程序 加 载 进 开 发 环境 中 〈 开 发 环境 是 MyEclipse， 有 具体 示例 时 
会 讲解 如 何 加 载 ) 。 

(2) 在 Java 程 序 中 加 载 驱 动 程 序 。 在 Java 程 序 中 ， 可 以 通 
过 “Class.forName(" 指 定数 据 库 的 驱动 程序 "的 方式 来 加 载 添 加 到 开发 
环境 中 的 驱动 程序 ， 例 如 加 载 MySQL 的 数据 驱动 程序 的 代码 为 
Class.forName("com.mysql.jdbc.Driver"). 

C3) 创建 数据 连接 对 象 。 通 过 DriverManager 类 创建 数据 库 连 接 
Connection。DriverManager 类 作用 于 Java 程 序 和 JDBC 驱 动 程序 之 

， 用 于 检查 所 加 载 的 驱动 程序 是 否 可 以 建立 连接 ， 然 后 通过 它 的 
pado 法 根据 数据 库 的 URL、 用 户 名 和 密码 ， 创 建 一 个 JDBC 
Connection 对 象 ， 例 如 : Connection connection = 
DriverManager.geiConnection(" 连 接 数 据 库 的 URL", "用 户 名 ", "密码 ”)。 
其 中 ，URL= 协 议 名 +IP 地 址 (域名 〉 + 端口 + 数据 库 名 称 ， 用 户 名 和 密码 
是 指 登录 数据 库 时 所 使 用 的 用 户 名 和 密码 。 具 体 示 例 创 建 MySQL 的 数 
据 库 连接 代码 如 下 : 





























Connection connectMySQL = 


DriverManager.geiConnection(“jdbc:mysql://localhost:3306/ 


Ww ow WOT 


myuser","root" ,"root" ); 

(4) 创建 Statement 对 象 。 nee 的 主要 是 用 于 执行 静态 SQL 

语句 并 返回 它 所 生成 结果 的 对 象 。 通 过 Connection 对 象 的 
createStatement() 方 法 可 以 创建 一 个 Sen 象 。 例 如 : Statement 
statament = connection.createStatement()。 具 体 示 例 创 建 Statement 对 象 代 
码 如 下 : 
Statement statamentMySQL oe UE 

(5) 调用 Statement 对 象 的 相关 方法 执行 相对 应 的 SQL 语句 。 
execuUpdate() 方 法 来 对 数据 更 新 ， 包 括 插入 和 删除 等 操作 ， 例 如 staff 
表 中 插入 一 条 数据 的 代码 : 


statement.excuteUpdate( "INSERT INTO staff(name, age, sex,address, 





depart, 

worklen, wage)" +" VALUES (‘Tom1', 321, 'M', 
'china',Personnel',3,3000' ) ") ; 

通过 调用 Statement 对 象 的 executeQuery0 方 法 进行 数据 的 查询 ， 而 
查询 结果 会 得 到 ResulSet 对 象 ，ResulSet 表示 执行 查询 数据 库 后 返回 的 
数据 的 集合 ，ResulSet 对 象 具有 可 以 指向 当前 数据 行 的 指针 。 通 过 该 对 
象 的 next0) 方 法 ， 使 得 指针 指向 下 一 行 ， 然 后 将 数据 以 列 号 或 者 字段 名 
取出 。 如 果 当 next0) 方 法 返回 null， 则 表示 下 一 行 中 没有 数据 存在 。 使 用 
示例 代码 如 下 : 

ResultSet resultSel = statement.executeQuery( "select * from staff" ); 

(6) 关闭 数据 库 连 接 。 使 用 完 数 据 库 或 者 不 需要 访问 数据 库 时 ， 

通过 Connection 的 close0) 方 法 及 时 关闭 数据 连接 。 
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Spring 中 的 JDBC 连 接 与 直接 使 用 JDBC 去 连接 还 是 有 所 差别 的 ， 
Spring 对 JDBC 做 了 大 量 封装 ， 消 除了 元 余 代 码 ， 使 得 开 及 量 大 大 减 小 。 
下 面 通过 一 个 小 例子 让 大 家 简单 认识 Spring 中 的 JDBC 操 作 。 

C1) 创建 数据 表 结 构 。 
CREATE TABLE 'user' ( 
id int(11) NOT NULL auto_increment, 
‘name' varchar(255) default NULL, 
'age' int(11) default NULL, 
'sex' varchar(255) default NULL, 
PRIMARY KEY (‘id’) 
) ENGINE-InnoDB DEFAULT CHARSET=utf8; 
(20 创建 对 应 数据 表 的 PO。 


public class User { 





private int id; 
private String name; 
private int age; 
private String sex; 
// 省 略 set/get 方 法 
} 
(3) 创建 表 与 实体 间 的 映射 。 
public class UserRowMapper implements RowMapper { 
@Override 
public Object mapRow(ResultSet set, int index) throws 
SQLException { 
User person = new User(set.getInt("id"), set.getString(" name"), set 
.getInt(" age"), set.getString("sex")); 


return person; 


} 
(4) 创建 数据 操作 接口 。 
public interface UserService { 
public void save(User user); 
public List<User> getUsers(); 
} 
(5) 创建 数据 操作 接口 实现 类 。 
public class UserServiceImpl implements UserService { 
private JdbcTemplate jdbcTemplate; 
/ 设置 数据 源 
public void setDataSource(DataSource dataSource) { 
this.jdbcTemplate = new JdbcTemplate(dataSource); 
} 
public void save(User user) { 
jdbcTemplate.update("insert into user(name,age,sex)values(?,?,?)", 
new Object[] { user.getName(), user.getAge(), 
user.getSex() }, new int[] { java.sql. Types. VARCHAR, 
java.sql. Types. INTEGER, java.sql. Types. VARCHAR J; 
} 
@SuppressWarnings("unchecked") 
public List<User> getUsers() { 
List<User> list = jdbcTemplate.query("select * from user", new 
UserRowMapper()); 


return list; 


(6) 创建 Spring 配置 文件 。 
<?xml version="1.0" encoding="UTF-8"?> 
«beans xmlIns="http://www.Springframework.org/schema/beans" 


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 

http://www.Springframework.org/schema/beans/Spring-beans- 
2.5.xsd 

"> 

<!-- 配 置 数据 源 --> 
<bean id="dataSource" 

class="org.apache.commons.dbcp.BasicDataSource" 

destroy-method="close"> 

<property name="driverClassName" 
value="com.mysql.jdbc.Driver" /> 

«property name-"url" 

value="jdbc:mysql://localhost:3306/lexueba" /> 

«property name-"username" value-"root" /> 

«property name-"password" value="haojia0421xixi" /> 

<!-- 连 接 池 启动 时 的 初始 值 --> 

<property name="initialSize" value="1" /> 

<!-- 连 接 池 的 最 大 值 --> 

<property name="maxActive" value="300" /> 

<l- 最 大 空闲 值 . 当 经 过 一 个 高 峰 时 间 后 ， 连 接 池 可 以 慢 慢 将 已 
经 用 不 到 的 连接 慢 慢 释放 一 部 分 ， 一 直 减 

少 到 maxIdle 为 止 --> 


<property name-"maxldle" value="2" /> 











<!-- 最 小 空 几 值 .当空 用 的 连接 数 少 于 阀 值 时 ， 连 接 池 就 会 预 申 
请 去 一 些 连接 ， 以 免 洪 峰 来 时 来 不 及 申请 --> 


<property name-"minlIdle" value="1" /> 





</bean> 

<!-- 配 置业 务 bean: PersonServiceBean --> 

<bean id="userService" class="service.UserServiceImpl"> 
<!-- 向 属性 dataSource 注 入 数据 源 --> 
<property name-"dataSource" ref="dataSource"></property> 

</bean> 

</beans> 
C7) 测试 。 
public class SpringJDBCTest { 

public static void main(String[] args) 1 

ApplicationContext act = new 
ClassPathXmlApplicationContext("bean.xml"); 
UserService userService = (UserService) 
act.getBean("userService"); 

User user = new User(); 
user.setName("3k ="); 
user.setA ge(20); 
user.setSex(" 53"); 
/ 保存 一 条 记录 
userService.save(user); 
List<User> person1 = userService.getUsers(); 
System.out.printIn("++++++++ 44 $i rfj User"); 
for (User person2 : person1) { 


System.out.printIn(person2.getId() + " " + person2.getName() 


+""+ person2.getAge() +"" + person2.getSex()); 








我 们 以 上 面 的 例子 为 基础 开始 分 析 Spring 中 对 JDBC 的 文 持 ， 首 先 寻 
找 整个 功能 的 切入 点 ， 在 示例 中 我 们 可 以 看 到 所 有 的 数据 库 操作 都 封装 
在 了 UserServiceImpl 中 ， 而 UserServiceImpl 中 的 所 有 数据 库 操 作 又 以 
其 内 部 属性 jdbcTemplate 为 基础 。 这 个 jdbcTemplate 可 以 作为 源码 分 析 的 
切入 点 ， 我 们 一 起 看 看 它 是 如 何 实现 又 是 如 何 被 初始 化 的 。 
在 UserServiceImpl 中 jdbcTemplate 的 初始 化 是 从 setDataSource rf 
数 开 始 的 ，DataSource 实 例 通 过 参数 注入 ，DataSource 的 创建 过 程 是 引 
入 第 三 方 的 连接 池 ， 这 里 不 做 过 多 介绍 。DataSource 是 整个 数据 库 操作 
的 基础 ， 里 面 封装 了 整个 数据 库 的 连接 信息 。 我 们 首先 以 保存 实体 类 为 
例 进行 代码 跟 踩 。 
public void save(User user) { 
jdbcTemplate.update("insert into user(name,age,sex)values(?,?,?)", 
new Object[] { user.getName(), user.getAge(), 
user.getSex() }, new int[] { java.sql. Types. VARCHAR, 
java.sql. Types. INTEGER, java.sql. Types. VARCHAR }); 
对 于 保存 一 个 实体 类 来 讲 ， 在 操作 中 我 们 只 需要 提供 SQL 语句 以 
及 语句 中 对 应 的 参数 和 参数 类 型 ， 其 他 操作 便 可 以 交 由 Spring 来 完成 
了 ， 这 些 工 作 到 底 包 括 什 么 呢 ? 进入 jdbcTemplate 中 的 update 方 法 。 
public int update(String sql, Object[] args, int[] argTypes) throws 


DataAccessException { 
return update(sql, newArgTypePreparedStatementSetter(args, 
argTypes)); 
} 
public int update(String sql, PreparedStatementSetter pss) throws 
DataAccessException { 
return update(new SimplePreparedStatementCreator(sql), pss); 
} 
进入 update 方法 后 ，Spring 并 不 是 急于 进入 核心 处 理 操作 ， 而 是 先 
做 足 准备 工作 ， 使 用 ArgTypePreparedStatementSetter 对 参数 与 参数 类 型 
进行 封 次 ， 同 时 又 使 用 Simple PreparedStatement Creator 对 SQL 语句 进行 
封装 。 至 于 为 什么 这 么 封装 ， 和 暂且 留 下 基 念 。 
经 过 了 数据 封装 后 便 可 以 进入 了 核心 的 数据 处 理 代 码 了 。 
protected int update(final PreparedStatementCreator psc, final 
PreparedStatementSetter pss) 
throws DataAccessException { 
logger.debug("Executing prepared SQL update"); 
return execute(psc, new PreparedStatementCallback<Integer>() 1 
public Integer doInPreparedStatement(PreparedStatement ps) 
throws 
SQLException { 
try { 
if (pss != null) { 
/设置 PreparedStatement 所 需 的 全 部 参数 。 
pss.setValues(ps); 
} 


int rows = ps.execute Update(); 


if (logger.isDebugEnabled()) { 
logger.debug(" SQL update affected " + rows + " rows"); 
} 
return rows; 
} 
finally { 
if (pss instanceof ParameterDisposer) { 


((ParameterDisposer) pss).cleanupParameters(); 


y 
} 
如 果 读 者 了 解 过 其 他 操作 方法 ， 可 以 知道 execute 方法 是 最 基础 的 
操作 ， 而 其 他 操作 比如 update、qduery 等 方法 则 是 传 入 不 同 的 
PreparedStatementCallback 人 参数 来 执行 不 同 的 逻辑 。 


8.2.1 基础 方法 execute 


execute 作 为 数据 库 操作 的 核心 入 口 ， 将 大 多 数 数据 库 操作 相同 的 步 
又 统一 封装 ， 而 将 个 性 化 的 操作 使 用 参数 PreparedStatementCallback 进 行 
回调 。 
public <T> T execute(PreparedStatementCreator psc, 
PreparedStatementCallback<T> action) 
throws DataAccessException { 
Assert.notNull(psc, "PreparedStatementCreator must not be null"); 
Assert.notNull(action, "Callback object must not be null"); 
if (logger.isDebugEnabled()) { 


String sql = getSql(psc); 
logger.debug("Executing prepared SQL statement" + (sql != null ? 
"["+sgql+"]": 
s 
j 
/获取 数据 库 连 接 
Connection con = DataSourceUtils.getConnection(getDataSource()); 
PreparedStatement ps = null; 
try { 
Connection conToUse = con; 
if (this.nativeJdbcExtractor != null && 
this.nativeJdbcExtractor.isNativeConnectionNecessaryForNative 
PreparedStatements()) { 
conToUse = 
this.nativeJdbcExtractor.getNativeConnection(con); 
} 
ps = psc.createPreparedStatement(conToUse); 
/应用 用 户 设 定 的 输入 参数 
applyStatementSettings(ps); 
PreparedStatement psToUse = ps; 
if (this.nativeJdbcExtractor != null) { 
psToUse = 
this.nativeJdbcExtractor.getNativePreparedStatement(ps); 
} 
/调用 回调 函数 
T result = action.doInPreparedStatement(psToUse); 


handleWarnings(ps); 


return result; 
} 
catch (SQLException ex) { 
1/ 释放 数据 库 连 接 避 免 当 RE PR A BA BI) 8 PB IRE f H 
潜在 的 连接 池 死 锁 
if (psc instanceof ParameterDisposer) { 


((ParameterDisposer) psc).cleanupParameters(); 


} 
String sql = getSql(psc); 
psc - null; 


JdbcUtils.closeStatement(ps); 

ps = null; 

DataSourceUtils.releaseConnection(con, getDataSource()); 
con - null; 

throw 


getExceptionTranslator().translate("PreparedStatementCallback", sql, ex); 
j 
finally 1 
if (psc instanceof ParameterDisposer) 1 
((ParameterDisposer) psc).cleanupParameters(); 
j 
JdbcUtils.closeStatement(ps); 


DataSourceUtils.releaseConnection(con, getDataSource()); 


) 
以 上 方法 对 常用 操作 进行 了 封装 ， 包 括 如 下 几 项 内 容 。 
1. 获取 数据 库 连 接 


获取 数据 库 连 接 也 并 非 直接 使 用 dataSource.getConnection() 方 法 那 
么 简单 ， 同 样 也 考虑 了 诸多 情况 。 
public static Connection doGetConnection(DataSource dataSource) 
throws SQLException { 
Assert.notNull(dataSource, "No DataSource specified"); 
ConnectionHolder conHolder = (ConnectionHolder) 
TransactionS ynchronization 
Manager.getResource(dataSource); 
if (conHolder != null && (conHolder.hasConnection() || 
conHolder.isSynchronized 
WithTransaction())) { 
conHolder.requested(); 
if (!conHolder.hasConnection()) { 
logger.debug("Fetching resumed JDBC Connection from 
DataSource"); 
conHolder.setConnection(dataSource.getConnection()); 
j 
return conHolder.getConnection(); 
j 
logger.debug("Fetching JDBC Connection from DataSource"); 
Connection con = dataSource.getConnection(); 
// 当 前 线程 支持 同步 
if (TransactionS ynchronizationManager.isSynchronizationActive()) { 
logger.debug("Registering transaction synchronization for JDBC 
Connection"); 
// 在 事务 中 使 用 同一 数据 库 连接 


ConnectionHolder holderToUse = conHolder; 


if (holderToUse == null) { 
holderToUse = new ConnectionHolder(con); 
} 
else { 
holderToUse.setConnection(con); 
} 
/记录 数据 库 连 接 
holderToUse.requested(); 
TransactionS ynchronizationManager.registerS ynchronization( 
new ConnectionSynchronization(holderToUse, dataSource)); 
holderToUse.setSynchronizedWithTransaction(true); 
if (holderToUse != conHolder) 1 
TransactionSynchronizationManager.bindResource(dataSource, 
holderToUse); 
j 
j 
return con; 
j 
在 数据 库 连 接 方 面 ，Spring 主 要 考虑 的 是 关于 事务 方面 的 处 理 。 基 
于 事务 处 理 的 特殊 性 ， Spring 需 要 保证 线程 中 的 数据 库 操作 都 是 使 用 同 
一 个 事务 连接 。 
2. 应 用 用 户 设 定 的 输入 参数 
protected void applyStatementSettings(Statement stmt) throws 
SQLException { 
int fetchSize = getFetchSize(); 
if (fetchSize > 0) { 
stmt.setFetchSize(fetchSize); 


} 
int maxRows = getMaxRows(); 
if (maxRows > 0) { 
stmt.setMaxRows(maxRows); 
j 
DataSourceUtils.applyTimeout(stmt, getDataSource(), 
getQueryTimeout()); 
j 
setFetchSize 最 主要 是 为 了 减少 网 络 交 互 次 数 设 计 的 。 访 问 ResultSet 
时 ， 如 果 它 每 次 只 从 服务 器 上 读 取 一 行 数据 ， 则 会 产生 大 量 的 开销 。 
setFetchSize 的 意思 是 当 调 用 rs.next 时 ，ResultSet 会 一 次 性 从 服务 右上 取 
得 多 少 行 数据 回来 ， 这 样 在 下 次 rs.next 时 ， 它 可 以 直接 从 内 存 中 获取 数 
据 而 不 需要 网 络 交 互 ， 提 高 了 效率 。 这 个 设置 可 能 会 被 茶 些 JDBC 驱动 
忽略 ， 而 且 设 置 过 大 也 会 造成 内 存 的 上 升 。 
setMaxRows 将 此 Statement 对 象 生成 的 所 有 ResultSet 对 象 可 以 包含 的 
最 大 行 数 限 制 设置 为 给 定数 。 
3. 调用 回调 函数 
处 理 一 些 通用 方法 外 的 个 性 化 处 理 ,也 就 是 
PreparedStatementCallback 类 型 的 参数 的 doInPreparedStatement 方 法 的 回 
调 。 











警告 处 理 
protected void handleWarnings(Statement stmt) throws SQLException { 
// 当 设置 为 忽略 警告 时 只 尝试 打印 日 志 
if (isIgnoreWarnings()) 1 
if (logger.isDebugEnabled()) 1 
/如果 日 志 开 启 的 情况 下 打印 日 志 
SQLWarning warningToLog = stmt.getWarnings(); 


while (warningToLog != null) { 

logger.debug("SQLWarning ignored: SQL state " + 
warning ToLog. 

getSQLState() + "', error code " + 

warning ToLog.getErrorCode() + ", message [" + 
warning ToLog. 

getMessage() + "J"; 

warning ToLog = warningToLog.getNextWarning(); 


} 
else { 


handleWarnings(stmt.getWarnings()); 


} 

这 里 用 到 了 一 个 类 SQLWarning，SQLWarning 提 供 关 于 数据 库 访问 
警告 信息 的 异常 。 这 些 警 告 直接 链接 到 导致 报告 警告 的 方法 所 在 的 对 
象 。 警 告 可 以 从 Connection、Statement 和 ResultSet 对 象 中 获得 。 试 图 在 
已经 关闭 的 连接 上 获取 警告 将 导致 抛 出 异常 。 类 似 地 ， 试 图 在 已 经 关闭 
的 语句 上 或 已 经 关闭 的 结果 集 上 获取 警告 也 将 导致 抛 出 异常 。 注 意 ， 关 
闭 语句 时 还 会 关闭 它 可 能 生成 的 结果 集 。 

很 多 人 不 是 很 理解 什么 情况 下 会 产生 警告 而 不 是 异常 ， 在 这 里 给 读 
者 提示 个 最 常见 的 警告 DataTruncation: DataTruncation 直 接 继 承 
SQLWarning， 由 于 某 种 原因 意外 地 截断 数据 值 时 会 以 DataTruncation 警 
告 形式 报告 异常 。 

对 于 警告 的 处 理 方式 并 不 是 直接 抛 出 异常 ， 出 现 警 告 很 可 能 会 出 现 
数据 错误 ， 但 是 ， 并 不 一 定 会 影响 程序 执行 ， 所 以 用 户 可 以 自己 设置 处 


























理 警 告 的 方式 ， 如 默认 的 是 忽略 警告 ， 当 出 现 警告 时 只 打印 警告 日 志 ， 
而 男 一 种 方式 只 直接 抛 出 异常 。 

5. 资源 释放 

数据 库 的 连接 释放 并 不 是 直接 调用 了 Connection 的 API 中 的 dlose 方 
法 。 考 虑 到 存在 事务 的 情况 ， 如 果 当 前 线程 存在 事务 ， 那 么 说 明 在 当前 
线程 中 存在 共用 数据 库 连 接 ， 这 种 情况 下 直接 使 用 ConnectionHolder 中 
的 released 方 法 进行 连接 数 减 一 ， 而 不 是 真正 的 释放 连接 。 


public static void releaseConnection(Connection con, DataSource 











dataSource) { 
try { 
doReleaseConnection(con, dataSource); 
} 
catch (SQLException ex) { 
logger.debug("Could not close JDBC Connection", ex); 
} 
catch (Throwable ex) { 
logger.debug("Unexpected exception on closing JDBC 
Connection", ex); 


} 


public static void doReleaseConnection(Connection con, DataSource 
dataSource) throws 
SQLException { 
if (con == null) { 
return; 
} 


if (dataSource != null) { 





/当前 线程 存在 事务 的 情况 下 说 明 存 在 共用 数据 库 连 接 直接 使 
用 ConnectionHolder 中 的 
released 方 法 进行 连接 数 减 一 而 不 是 真正 的 释放 连接 。 


ConnectionHolder conHolder = (ConnectionHolder) 








TransactionSynchronization 
Manager.getResource(dataSource); 
if (conHolder != null && connectionEquals(conHolder, con)) { 
// It's the transactional Connection: Don't close it. 
conHolder.released(); 


return; 


} 
if (!'(dataSource instanceof SmartDataSource) || ((SmartDataSource) 
dataSource). shouldClose(con)) { 
logger.debug(" Returning JDBC Connection to DataSource"); 


con.close(); 





PreparedStatementCallback 作 为 一 个 接口 ， 其 中 只 有 一 个 函数 
doInPreparedStatement， 这 个 函数 是 用 于 调用 通用 方法 execute 的 时 候 无 
法 处 理 的 一 些 个 性 化 处 理 方法 ， 在 update 中 的 函数 实现 : 

public Integer doInPreparedStatement(PreparedStatement ps) throws 
SQLException { 

try { 
if (pss != null) { 


/设置 PreparedStatement 所 需 的 全 部 参数 。 
pss.setValues(ps); 
} 
int rows = ps.executeUpdate(); 
if (logger.isDebugEnabled()) { 
logger.debug("SQL update affected " + rows + " rows"); 
} 
return rows; 
} 
finally { 
if (pss instanceof ParameterDisposer) { 


((ParameterDisposer) pss).cleanupParameters(); 


} 

其 中 用 于 真正 执行 SQL 的 ps.executeUpdate 没 有 太 多 需要 讲解 的 ， 
为 我 们 平时 在 直接 使 用 JDBC 方 式 进行 调用 的 时 候 会 经 常 使 用 此 方法 。 
但 是 ， 对 于 设置 输入 参数 的 函数 pss.setValues (ps)， 我 们 有 必要 去 深入 
研究 一 下 。 在 没有 分 析 源 码 之 前 ， 我 们 人 至少 可 以 知道 其 功能 ， 不 妨 再 回 
顾 下 Spring 中 使 用 SQL 的 执行 过 程 ， 直 接 使 用 : 

jdbcTemplate.update("insert into user(name,age,sex)values(?,?,?)", 

new Object[] { user.getName(), user.getAge(), 

user.getSex() }, new int[] { java.sql. Types. VARCHAR, 

java.sql. Types. INTEGER, java.sql. Types. VARCHAR }); 

SQL 语句 对 应 的 参数 ， 对 应 参数 的 类 型 清晰 明了 ， 这 都 归功 于 
Spring 为 我 们 做 了 封装 ， 而 真正 的 JDBC 调 用 其 实 非常 繁琐 ， 你 需要 这 人 么 
做 : 


PreparedStatement updateSales = con.prepareStatement("insert into 
user(name,age, 
sex)values(?,?,?)"); 
updateSales.setString(1, user.getName()); 
updateSales.setInt(2, user.getA ge()); 
updateSales.setString(3, user.getSex()); 
那么 看 看 Spring 是 如 何 做 到 封装 上 面 的 操作 呢 ? 
首先 ， 所 有 的 操作 都 是 以 pss.setValues(ps) 为 入 口 的 。 还 记得 我 们 之 
前 的 分 析 路 程 吗 ? 这 个 pss 所 代表 的 当前 类 正 是 
ArgPreparedStatementSetter。 其 中 的 setValues 如 下 : 
public void setValues(PreparedStatement ps) throws SQLException { 
int parameterPosition = 1; 
if (this.args != null) { 
/ 通 历 每 个 参数 以 作 类 型 匹配 及 转换 
for (int i = 0; i < this.args.length; i++) { 
Object arg = this.args[i]; 
/如 果 是 集合 类 则 需要 进入 集合 类 内 部 递归 解析 集合 内 部 属 





性 
if (arg instanceof Collection && this.argTypes[i] != 
Types.ARRAY) { 
Collection entries = (Collection) arg; 
for (Iterator it = entries.iterator(); it.hasNext();) { 
Object entry = it.next(); 
if (entry instanceof Object[]) { 
Object[] valueArray = ((Object[])entry); 
for (int k = 0; k < valueArray.length; k++) { 
Object argValue = valueArray[k]; 


doSetValue(ps, parameterPosition, this.argTypes[i], 
argValue); 
parameterPosition++; 
} 
}else { 
doSetValue(ps, parameterPosition, this.argTypes[i], 
entry); 


parameterPosition++; 


}else { 
/解析 当前 属性 
doSetValue(ps, parameterPosition, this.argTypes[i], arg); 


parameterPosition++; 


} 
对 单个 参数 及 类 型 的 匹配 处 理 : 


protected void doSetValue(PreparedStatement ps, int parameterPosition, 





int argType, Object argValue) 
throws SQLException { 
StatementCreatorUtils.setParameterValue(ps, parameterPosition, 
argType, arg Value); 
} 
public static void setParameter Value( 


PreparedStatement ps, int paramIndex, int sqlT ype, Object inValue) 


throws SQLException { 
setParameterValueInternal(ps, paramIndex, sqlType, null, null, 
inValue); 
j 
private static void setParameterV alueInternal( 
PreparedStatement ps, int paramIndex, int sql Type, String typeName, 
Integer 
scale, Object inValue) 
throws SQLException 1 
String typeNameToUse = typeName; 
int sqlTypeToUse = sqlType; 
Object inValueToUse - inValue; 
if (inValue instanceof SqlParameterValue) { 
SqlParameter Value parameterValue = (SqlParameterValue) 
inValue; 
if (logger.isDebugEnabled()) 1 
logger.debug("Overriding type info with runtime info from 
SqlParameterValue: 
column index " + paramIndex + 
", SQL type " + parameterValue.getSqlType() + 
", Type name " + parameterValue.getTypeName()); 
} 
if (parameterValue.getSqlType() != 
SqlTypeValue. TYPE UNKNOWN) { 
sqlTypeToUse = parameterValue.getSql Type(); 


} 
if (parameterValue.getT ypeName() != null) { 


typeNameToUse = parameterValue.getIypeName(); 
} 
inValueToUse = parameterValue.getV alue(); 
} 
if (logger.isTraceEnabled()) { 
logger.trace(" Setting SQL statement parameter value: column 
index " + 
paramIndex + 
", parameter value [" + inValueToUse + 
"], value class [" + (inValueToUse != null ? inValueToUse. 
getClass().getName() : "null") + 
"] SQL type " + (sqlTypeToUse == 
SqlTypeValue.TYPE_UNKNOWN ? 
"unknown" : Integer.toString(sql TypeToUse))); 
j 
if (inValueToUse == null) { 
setNull(ps, paramIndex, sql TypeToUse, typeNameToUse); 
j 
else { 
setValue(ps, paramIndex, sqlTypeToUse, typeNameToUse, scale, 
inValueToUse); 
} 
} 


8.3 query 功 能 的 实现 


在 之 前 的 章节 中 我 们 介绍 了 update 方 法 的 功能 实现 ， 那 么 在 数据 库 


操作 中 碍 找 操作 也 是 使 用 率 非常 高 的 函数 ， 同 样 我们 也 需要 了 解 它 的 实 
现 过 程 。 使 用 方法 如 下 : 
List<User> list = jdbcTemplate.query("select * from user where 
age=?" new 
Object[]{20},new int[]{java.sql. Types. INTEGER} ,new 
UserRowMapper()); 
跟踪 jdbcTemplate 中 的 query 方 法 。 
public <T> List<T> query(String sql, Object[] args, int[] argTypes, 
RowMapper<T> rowMapper) 
throws DataAccessException { 
return query(sql, args, argTypes, new 
RowMapperResultSetExtractor<T> 
(rowMapper)); 
} 
public <T> T query(String sql, Object[] args, int[] argTypes, 
ResultSetExtractor<T> rse) 
throws DataAccessException { 
return query(sql, newArgTypePreparedStatementSetter(args, 
arg Types), rse); 
} 
上 面 函 数 中 与 update 方 法 中 都 同样 使 用 了 
newArgTypePreparedStatementSetter . 
public <T> T query(String sql, PreparedStatementSetter pss, 
ResultSetExtractor<T> rse) 
throws DataAccessException { 


return query(new SimplePreparedStatementCreator(sql), pss, rse); 


public <T> T query( 
PreparedStatementCreator psc, final PreparedStatementSetter pss, final 
ResultSetExtractor<T> rse) 
throws DataAccessException { 
Assert.notNull(rse, "ResultSetExtractor must not be null"); 
logger.debug("Executing prepared SQL query"); 
return execute(psc, new PreparedStatementCallback<T>() 1 
public T doInPreparedStatement(PreparedStatement ps) throws 
SQLException 1 
ResultSet rs = null; 
try 1 
if (pss != null) 1 
pss.setValues(ps); 
j 
rs = ps.executeQuery(); 
ResultSet rsToUse = rs; 
if (nativeJdbcExtractor != null) { 
rsToUse = nativeJdbcExtractor.getNativeResultSet(rs); 
} 
return rse.extractData(rs ToUse); 
i 
finally { 
JdbcUtils.closeResultSet(rs); 
if (pss instanceof ParameterDisposer) 1 


((ParameterDisposer) pss).cleanupParameters(); 


y 

} 

可 以 看 到 整体 套路 与 update 差 不 多 的 ， 只 不 过 在 回调 类 
PreparedStatementCallback 的 实现 中 使 用 的 是 ps.executeQueryO 执 行 查 询 
操作 ， 而 且 在 返回 方法 上 也 做 了 一 些 额外 的 处 理 。 

Ise.extractData(rsToUse) 方 法 负责 将 结果 进行 封装 并 转换 至 POJO, 
rse 当前 代表 的 类 为 RowMapperResultSetExtractor， 而 在 构造 
RowMapperResultSetExtractor 的 时 候 我 们 又 将 自 定 义 的 rowMapper 设 置 
了 进去 。 调 用 代码 如 下 : 

public List<T> extractData(ResultSet rs) throws SQLException { 

List<T> results = (this.rowsExpected > 0 ? new ArrayList<T> 
(this.rowsExpected) : 

new ArrayList<T>()); 

int rowNum = 0; 

while (rs.next()) { 

results.add(this.rowMapper.mapRow(rs, rowNum++)); 

} 

return results; 

} 

上 面 的 代码 中 并 没有 什么 复杂 的 逻辑 ， 只 是 对 返回 结果 遍历 并 以 此 
使 用 rowMapper 进 行 转换 。 

之 前 讲 了 update 方 法 以 及 query 方 法 ， 使 用 这 两 个 函数 示例 的 SQL 都 
是 带 有 参数 的 ， 也 就 是 带 有 “? ”的 ， 那 么 还 有 另 一 种 情况 是 不 市 
有 ”2 的 ，Spring 中 使 用 的 是 另 一 种 处 理 方式 。 例 如 : 


List<User> list = jdbcTemplate.query("select * from user", new 





UserRowMapper()); 


跟踪 进入 : 
public <T> List<T> query(String sql, RowMapper<T> rowMapper) 
throws DataAccessException { 
return query(sql, new RowMapperResultSetExtractor<T> 
(rowMapper)); 
} 
public <T> T query(final String sql, final ResultSetExtractor<T> rse) 
throws 
DataAccessException { 
Assert.notNull(sql, "SQL must not be null"); 
Assert.notNull(rse, "ResultSetExtractor must not be null"); 
if (logger.isDebugEnabled()) 1 
logger.debug("Executing SQL query [" + sql + "J"; 
j 
class QueryStatementCallback implements StatementCallback<T>, 
SqlProvider 1 
public T doInStatement(Statement stmt) throws SQLException 1 
ResultSet rs = null; 
try 1 
rs = stmt.executeQuery(sql); 
ResultSet rsToUse - rs; 
if (nativeJdbcExtractor != null) { 
rsToUse = nativeJdbcExtractor.getNativeResultSet(rs); 
j 
return rse.extractData(rsToUse); 


} 
finally { 


JdbcUtils.closeResultSet(rs); 


} 
public String getSql() { 


return sql; 


} 
return execute(new QueryStatementCallback()); 
j 
与 之 前 的 query 方法 最 大 的 不 同 是 少 了 参数 及 参数 类 型 的 传递 ， 目 
然 也 少 了 Prepared StatementSetter 类 型 的 封装 。 既 然 少 了 
PreparedStatementSetter 类 型 的 传 入 ， 调 用 的 execute 方 法 目 然 也 会 有 所 改 
CNET 
public «T» T execute(StatementCallback<T> action) throws 
DataA ccessException 1 
Assert.notNull(action, "Callback object must not be null"); 
Connection con = DataSourceUtils.getConnection(getDataSource()); 
Statement stmt = null; 
try 1 
Connection conToUse = con; 
if (this.nativeJdbcExtractor != null && 
this.nativeJdbcExtractor.isNativeConnectionNecessary ForNative 
Statements()) 1 
conToUse = 
this.nativeJdbcExtractor.getNativeConnection(con); 
j 


stmt = conToUse.createStatement(); 


applyStatementSettings(stmt); 
Statement stmtToUse = stmt; 
if (this.nativeJdbcExtractor != null) { 
stmtToUse = this.nativeJdbcExtractor.getNativeStatement(stmt); 
} 
T result = action.doInStatement(stmtToUse); 
handleWarnings(stmt); 
return result; 
} 
catch (SQLException ex) { 
// Release Connection early, to avoid potential connection pool 


deadlock 
// in the case when the exception translator hasn't been initialized 


yet. 
JdbcUtils.closeStatement(stmt); 


stmt = null; 
DataSource Utils.releaseConnection(con, getDataSource()); 
con = null; 
throw getExceptionTranslator().translate("StatementCallback", 
getSql(action), ex); 

} 

finally { 
JdbcUtils.closeStatement(stmt); 
DataSourceUtils.releaseConnection(con, getDataSource()); 


} 
这 个 exexute 与 之 前 的 execute 并 无 太 大 拳 别 ， 都 是 做 一 些 和 常规 的 处 





理 ， 诸 如 获取 连接 、 释 连接 等 ， 但 是 ， 有 一 个 地 方 是 不 一 样 的 ， 就 是 
statement 的 创建 。 这 里 直接 使 用 connection 创 建 ， 而 带 有 参数 的 SQL 使 用 
的 是 PreparedStatementCreator 类 来 创建 的 。 一 个 是 普通 的 Statement， 男 
一 个 是 PreparedStatement， 两 者 究竟 是 何 区 别 呢 ? 

PreparedStatement 接 口 继承 Statement， 并 与 之 在 两 方面 有 所 不 同 。 

PreparedStatement 实 例 包 含 已 编译 的 SQL 语 句 。 这 就 是 使 语句 “准备 
好 ”。 包 含 于 PreparedStatement 对 象 中 的 SQL 语句 可 具有 一 个 或 多 个 IN 参 
数 。IN 参 数 的 值 在 SQL 语句 创建 时 未 被 指定 。 相 反 的 ， 该 语句 为 每 个 
IN 参 数 保留 一 个 问号 《"?") 作为 占 位 符 。 每 个 问号 的 值 必须 在 该 语句 
执行 之 前 ， 通 过 适当 的 setXXX 方 法 来 提供 。 

由 于 PreparedStatement 对 象 已 预 编 译 过 ， 所 以 其 执行 速度 要 快 于 
Statement 对 象 。 因 此 ， 多 次 执行 的 SQL 语句 经 党 创建 为 
PreparedStatement 对 象 ， 以 提高 效率 。 

作为 Statement 的 子 类 ，PreparedStatement 继 承 了 Statement 的 所 有 功 
能 。 男 外 ， 它 还 添加 了 一 整套 方法 ， 用 于 设置 发 送 给 数据 库 以 取代 IN 参 
数 占 位 符 的 值 。 同 时 ， 三 种 方法 execute、executeQuery 和 executeUpdate 
已 被 更 改 以 使 之 不 再 需要 参数 。 这 些 方法 的 Statement 形 式 〈 接 受 SQL 语 
名 参数 的 形式 ) 不 应 该 用 于 PreparedStatement 对 象 。 








8.4 queryForObject 


Spring 中 不 仅仅 为 我 们 提供 了 query 方 法 ， 还 在 此 基础 上 做 了 封装 ， 
提供 了 不 同类 型 的 query 方 法 ， 如 图 8-1 所 示 。 





4 K9 JdbcTemplate 
© 4 queryForMap(String) : Map «String, Object= 
9 4 queryForObject(String, RowMapper«T») «T» :T 
9 4 queryForObject(String, Class«T») «T» :T 
6 4 queryForLong(String) : long 
9 4 queryForint(String) : int 
© 4 queryForList(String, Class«T») «T» :List<T> 
© 4 queryForList(String) : Liste Map «String, Object» > 
6 4 queryForRowSet(String) : SqlRowSet 
6 4 queryForObject(String, Object[], int[], RowMapper<T=) «T» :T 
9 4 queryForObject(String, Object[], RowMapper«T») «T» :T 
© 4 queryForObject(String, RowMapper<T=, Object...) «T» :T 
9 4 queryForObject(String, Object[], int[], Class«T») «T» :T 
9 a queryForObject(String, Object[], Class«T») «T» :T 
6 4 queryForObject(String, Class <T>, Object...) «T> :T 
© 4 queryForMap(String, Object[], int[]) : Map «String, Object» 
© 4 queryForMap(String, Object...) : Map «String, Object» 
9 4 queryForLong(String, Object], int[]) : long 
9 4 queryForLong(String, Object...) : long 
© 4 queryForlnt(String, Object[], int[]) : int 
9 4 queryForint(String, Object...) : int 
© 4 queryForList(String, Object[], int[], Class<T>) «T» : List<T= 
9 a queryForList(String, Object[], Class <T>) «T» : List<T> 
© 4 queryForList(String, Class«T», Object...) «T» :List« T» 
© 4 queryForList(String, Object[], int[]) : Liste Map «String, Object» = 
© 4 queryForList(String, Object...) : List« Map «String, Object» > 
© 4 queryForRowSet(String, Object[], int[] : SalRowSet 
9 4 queryForRowSet(String, Object...) : SqlRowSet 








图 8-1 Spring 中 的 query 相 关 方 法 


我 们 以 queryForObject 为 例 ， 来 讨论 一 下 Spring 是 如 何在 返回 结果 的 
基础 上 进行 封装 的 。 
public <T> T queryForObject(String sql, Class<T> requiredType) 
throws DataAccessException { 
return queryForObject(sql, 
getSingleColumnRowMapper(requiredType)); 


} 
public <T> T queryForObject(String sql, RowMapper<T> rowMapper) 
throws DataAccessException { 
List<T> results = query(sql, rowMapper); 
return DataAccessUtils.requiredSingleResult(results); 
} 
其 实 最 大 的 不 同 还 是 对 于 RowMapper 的 使 用 。 
SingleColumnRowMapper 类 中 的 mapRow: 





public T mapRow(ResultSet rs, int rowNum) throws SQLException { 
// 验 证 返回 结果 数 
ResultSet MetaData rsmd = rs.getMetaData(); 
int nrOfColumns = rsmd.getColumnCount(); 
if (nrOfColumns != 1) { 
throw new IncorrectResultSetColumnCountException(1, 
nrOfColumns); 
} 
/抽取 第 一 个 结果 进行 处 理 
Object result = getColumnValue(rs, 1, this.requiredType); 
if (result != null && this.requiredType != null && 
Ithis.requiredType. 
isInstance(result)) 1 
/转换 到 对 应 的 类 型 
try { 
return (T) convertValueToRequiredType(result, 
this.requiredType); 
} 
catch (IllegalArgumentException ex) { 


throw new TypeMismatchDataAccessException( 

"Type mismatch affecting row number " + rowNum + " and 
column 

type " + 

rsmd.getColumnTypeName(1) + ": " + ex.getMessage()); 


} 
return (T) result; 
} 
对 应 的 类 型 转换 函数 : 
protected Object convertValueToRequiredType(Object value, Class 
requiredType) { 
if (String.class.equals(requiredType)) { 
return value.toString(); 
} 
else if (Number.class.isAssignableFrom(requiredType)) { 
if (value instanceof Number) { 
// Convert original Number to target Number class. 
/转换 原始 Number 类 型 的 实体 到 Number 类 


return NumberUtils.convertNumberToTargetClass(((Number) 


value), 
requiredT ype); 
}else { 
/转换 string 类 型 的 值 到 Number 类 
return NumberUtils.parseNumber(value.toString(), 
requiredT ype); 


} 


} 
else { 
throw new IllegalArgumentException( 
"Value [" + value + "| is of type [" + value.getClass().getName() + 
"] and cannot be converted to required type [" + requiredType. 
getName() + "|"); 
j 


Or 4 4MyBatis 


MyBatis 本 是 Apache 的 一 个 开源 项 目 iBatis，2010 年 这 个 项 目 由 
Apache Software Foundation 迁 移 到 了 Google Code， 并 且 改 名 为 
MyBatis C FX IE Zyhttp://code.google.com/p/mybatis/) 。 

MyBatiszé x FE SQL £n. fx S E ZUM EUG RE AU 
框架 。MyBatis 消 除了 几乎 所 有 的 JDBC 代 码 和 参数 的 手工 设置 以 及 结 
集 的 检索 。MyBatis 使 用 简单 的 XML 或 注解 用 于 配置 和 原始 映射 ， 将 接 
口 和 Java 的 POJOs (Plain Old Java Objects， 普 通 的 Java 对 象 ) 映射 成 数 
据 库 中 的 记录 。 


9.1 MvBatis 独 立 


尽管 我 们 接触 更 多 的 是 MyBatis 与 Spring 的 整合 使 用 ， 但 是 MyBatis 
有 它 自 己 的 独立 使 用 方法 ， 了 人 解 其 独立 使 用 的 方法 套路 对 分 析 Spring 整 
合 MyBatis 非 常 有 帮助 ， 因 为 Spring 无 非 就 是 将 这 些 功能 进行 封装 以 简化 
我 们 的 开发 流程 。MyBatis 独 立 使 用 包括 以 下 几 步 。 
(1) 建立 PO。 





用 于 对 数据 库 中 数据 的 映射 ， 使 程序 员 更 关注 于 对 Java 类 的 使 用 而 
不 是 数据 库 的 操作 。 
public class User { 
private Integer id; 
private String name; 
private Integer age; 
// 省 略 set/get 方 法 
public User(String name, Integer age) { 
super(); 
this.name = name; 
this.age = age; 
} 
public User() { 
super(); 
} // 必 须要 有 这 个 无 参 构 造 方法 ， 不 然 根据 UserMapper.xml 中 的 
配置 ， 在 查询 数据 库 时 ， 将 不 能 反射 构造 出 
User 实 例 
} 
(2) 建立 Mapper。 
数据 库 操作 的 映射 文件 ， 也 就 是 我 们 常 利 说 的 DAO， 用 于 映射 数 
据 库 的 操作 ， 可 以 通过 配置 文件 指定 方法 对 应 的 SQL 语句 或 者 直接 使 用 
Java 提 供 的 注解 方式 进行 SQL 指定 。 
public interface UserMapper { 
public void insertUser(User user); 
public User getUser(Integer id); 
} 
(3) 建立 配置 文件 。 








配置 文件 主要 用 于 配置 程序 中 可 变性 高 的 设置 ， 一 个 偏 大 的 程序 一 
定 会 存在 一 些 经 常会 变化 的 变量 ， 如 果 每 次 变化 都 需要 改变 源码 那 会 是 
非常 糟 糙 的 设计 ， 所 以 ， 我 们 看 到 各 种 各 样 的 框架 或 者 应 用 的 时 候 都 免 
不 了 要 配置 配置 文件 ，MyBatis 中 的 配置 文件 主要 封装 在 configuration 
中 ， 配 置 文件 的 基本 结构 如 图 9-1 所 示 。 

















E objectFactory 


图 9-1 配置 文件 结构 


configuration: 根 元 素 。 

properties: 定义 配置 外 在 化 。 

settings: 一 些 全 局 性 的 配置 。 

typeAliases: 为 一 些 类 定义 别名 。 

typeHandlers: 定义 类 型 处 理 ， 也 就 是 定义 Java 类 型 与 数据 库 中 的 
数据 类 型 之 间 的 转换 关系 。 

objectFactory: 用 于 指定 结果 集 对 象 的 实例 是 如 何 创 建 的 。 

plugins: MyBatis 的 插件 ， 插 件 可 以 修改 MyBatis 内 部 的 运行 规则 。 

environments: 环境 。 

environment: 配置 MyBatis 的 环境 。 

transactionManager: 事务 管理 器 。 











dataSource: 数据 源 。 
mappers: 指定 映射 文件 或 映射 类 。 
读者 如 果 对 上 面 的 各 个 配置 具体 使 用 方法 感 兴 趣 ， 可 以 进一步 查阅 
相关 资料 ， 这 里 只 举 出 最 简单 的 实例 以 方便 读者 快速 回顾 MyBatis。 
<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE configuration 
PUBLIC "-//mybatis.org//DTD Config 3.0//EN" 
"http://mybatis.org/dtd/mybatis-3-config.dtd"> 
<configuration> 
<settings> 
<!-- changes from the defaults for testing --> 
<setting name="cacheEnabled" value="false" /> 
«setting name-"useGeneratedK eys" value="true" /> 
«setting name-"defaultExecutorType" value="REUSE" /> 
</settings> 
<typeAliases> 
«typeAlias alias="User" type="bean.User"/> 
</typeAliases> 
<environments default="development"> 
«environment id="development"> 
«transactionManager type="jdbc"/> 
<dataSource type="POOLED"> 
<property name="driver" value="com.mysql.jdbc.Driver"/> 
«property name="url" 
value="jdbc:mysql://localhost/lexueba"/> 
<property hame="username" value="root"/> 


<property name-"password" value="haojia0421xixi"/> 


</dataSource> 
</environment> 
</environments> 
«mappers^ 
«mapper resource-"resource/UserMapper.xml" /> 
</mappers> 
</configuration> 
(4) 建立 映射 文件 。 
对 应 于 MyBaits 全 局 配置 中 的 mappers 配置 属性 ， 主 要 用 于 建立 对 
应 数据 库 操作 接口 的 SQL 映射 。MyBatis 会 将 这 里 设 定 的 SQL 与 对 应 的 
Java 接 口 相关 联 ， 以 保证 在 MyBatis 中 调用 接口 的 时 候 会 到 数据 库 中 执 
行 相 应 的 SQL 来 简化 开发 。 
<?xml version="1.0" encoding="UTF-8" ?> 
<!DOCTY PE mapper 
PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" 
"http://mybatis.org/dtd/mybatis-3-mapper.dtd"> 
<mapper namespace=""Mapper.UserMapper'"> 
<!-- 这 里 namespace 必须 是 UserMapper 接口 的 路 径 ， 不 然 要 运行 的 
时 候 要 报错 “is not known to the 


MapperRegistry”--> 





«insert id="insertUser" parameterType- "User" > 
insert into user(name,age) values(#{name},#{age}) 
<!-- 这 里 sql 结 尾 不 能 加 分 写 ， 否 则 报 “ORA-00911” 的 错误 --> 
</insert> 
<!-- 这 里 的 id 必 须 和 UserMapper 接 口中 的 接口 方法 名 相同 ， 不 然 
运行 的 时 候 也 要 报错 --> 


<select id="getUser" resultType="User" 


parameterType="java.lang.Integer" > 
select * from user where id=#{id} 
</select> 
</mapper> 
(5) 建立 测试 类 。 

至 此 我 们 已 经 完成 了 MyBatis 的 建立 过 程 ， 接 下 来 的 工作 就 是 对 之 
前 的 所 有 工作 进行 测试 ， 以 便 直接 查看 MyBatis 为 我 们 提供 的 效果 。 

public class MyBatisUtil { 

private final static SqlSessionFactory sqlSessionFactory; 





Static { 
String resource = "resource/mybatis-config.xml"; 


Reader reader = null; 


try { 
reader = Resources.getResourceAsReader(resource); 


} catch (IOException e) { 
System.out.printIn(e.getMessage()); 

} 

sqlSessionFactory = new 


SqlSessionFactory Builder().build(reader); 


} 
public static SqlSessionFactory getSqlSessionFactory() 1 


return sqlSessionFactory; 


} 
public class TestMapper { 
static SqlSessionFactory sqlSessionFactory = null; 


Static { 


sqlSessionFactory = MyBatisUtil.getSqlSessionFactory(); 
} 
@Test 
public void testAdd() { 
SqlSession sqlSession = sqlSessionFactory.openSession(); 
try 1 
UserMapper userMapper = 
sqlSession.getMapper(UserMapper.class); 
User user = new User("tom",new Integer(5)); 
userMapper.insertUser(user); 
sqlSession.commit();// 这 里 一 定 要 提交 ， 不 然 数 据 进 不 去 数据 
库 中 
} finally { 


sqlSession.close(); 


} 
@Test 
public void getUser() { 
SqlSession sqlSession = sqlSessionFactory.openSession(); 
try { 
UserMapper userMapper = 
sqlSession.getMapper(UserMapper.class); 
User user = userMapper.getUser(1); 
System.out.printIn("name: "+user.getName()+" lage: 
"+user.getA ge()); 
} finally { 


sqlSession.close(); 


} 

注意 ， 这 里 在 数据 库 设 定 了 id 目 增 胰 略 ， 所 以 插入 的 数据 会 直接 在 
数据 库 中 赋值 ， 当 执行 测试 后 如 果 数 据 表 为 空 ， 那 么 在 表 中 会 出 现 一 条 
我 们 插入 的 数据 ， 并 会 在 查询 时 将 此 数据 得 出 。 


9.2 Spring 整合 MyBatis 


了 解 了 MyBatis 的 独立 使 用 过 程 后 ， 我 们 再 看 看 它 与 Spring 整合 的 使 
用 方式 ， 比 对 之 前 的 示例 来 找 出 Spring 究竟 为 我 们 做 了 哪些 操作 来 简化 
程序 员 的 业务 开 及 。 由 于 在 上 面 示例 基础 上 作 更 改 ， 所 以 ，User 与 
UserMapper 保 持 不 变 。 

(1) Spring 配置 文件 。 

配置 文件 是 Spring 的 核心 ，Spring 的 所 有 操作 也 都 是 由 配置 文件 开 
始 的 ， 所 以 ， 我 们 的 示例 也 首先 从 配置 文件 开始 。 

<?xml version="1.0" encoding="UTF-8"?> 

«beans xmlns="http://www.Springframework.org/schema/beans" 


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www.Springframework. 
org/ schema/beans/Spring-beans-3.0.xsd"> 
<bean id="dataSource" 
class="org.apache.commons.dbcp.BasicDataSource"> 
<property name="driverClassName" 


value="com.mysql.jdbc.Driver"></property> 


<property name="url" 
value="jdbc:mysql://localhost:3306/lexueba?useUnicode= 
true&amp;characterEncoding-UTF- 
8&amp;zeroDateTimeBehavior=convertToNull"></property> 
<property hame="username" value="root"></property> 
<property name-"password" value="haojia0421xixi"></property> 
<property name-"maxActive" value="100"></property> 
<property name="maxlIdle" value="30"></property> 
<property name="max Wait" value="500"></property> 
<property name-"defaultAutoCommit" value="true"></property> 
</bean> 
<bean id="sqlSessionFactory" 
class="org.mybatis.Spring.SqlSessionFactoryBean"> 
<property name="configLocation" 
value="classpath:test/mybatis/MyBatis-Configuration. 
xml"></property> 
<property name-"dataSource" ref="dataSource" /> 
</bean> 
<bean id="userMapper" 
class="org.mybatis.Spring.mapper.MapperFactoryBean"> 
<property name-"mapperlInterface" 
value="test.mybatis.dao.UserMapper"></property> 
<property name-"sqlSessionFactory" ref="sqlSessionFactory"> 
</property> 
</bean> 
</beans> 


对 比 之 前 独立 使 用 MyBatis 的 配置 文件 ， 我 们 发 现 ， 之 前 在 





environments 中 设置 的 dataSource 被 转移 到 了 Spring 的 核心 配置 文件 中 
管理 。 而 且 ， 针 对 于 MyBatis ， 注 册 了 
org.mybatis.Spring.SqlSessionFactoryBean 类 型 bean， 以 及 用 于 映射 接口 
的 org.mybatis.Spring. mapper.MapperFactoryBean， 这 两 个 bean 的 作用 我 
们 会 在 稍 后 分 析 。 

之 前 我 们 了 解 到 ，MyBatis 提供 的 配置 文件 包含 了 诸多 属性 ， 虽 然 
大 多 数 情况 我 们 都 会 保持 MyBatis 原 有 的 风格 ， 将 MyBatis 的 配置 文件 独 
立 出 来 ， 并 在 Spring 中 的 org.mybatis.Spring. SqlSessionFactoryBean 类 型 
的 bean 中 通过 configLocation 属 性 引入 ， 但 是 ， 这 并 不 代表 Spring 不 支持 
直接 配置 。 以 上 面 示例 为 例 ， 你 完全 可 以 省 去 MyBatis- 
Configuration.xml， 而 将 其 中 的 配置 以 属性 的 方式 注入 到 
SqlSessionFactoryBean 中 ， 人 至 于 每 个 属性 名 称 以 及 用 法 ， 我 们 会 在 后 面 
的 章节 中 进行 详细 的 分 析 。 

(2) MyBatis 配 置 文件 。 

对 比 独 立 使 用 MyBatis 时 的 配置 文件 ， 当 前 的 配置 文件 除了 移 除 
environments 配 置 外 并 没有 太 多 的 变化 。 

<?xml version="1.0" encoding="UTF-8" ?> 

<!DOCTYPE configuration PUBLIC "-//mybatis.org//DTD Config 
3.0//EN" 

"http://mybatis.org/dtd/mybatis-3-config.dtd"> 





<configuration> 
<typeAliases> 
<typeAlias alias="User" type="test.mybatis.bean.User"/> 
</typeAliases> 
«mappers^ 
«mapper resource="test/mybatis/UserMapper.xml"/> 


</mappers> 


</configuration> 
(3) 映射 文件 (保持 不 变 ) 。 

<?xml version="1.0" encoding="UTF-8" ?> 

<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" 
"http://mybatis.org/ 

dtd/mybatis-3-mapper.dtd"> 

<mapper namespace="test.mybatis.dao. UserMapper"> 

«insert id="insertUser" parameterType- "User" > 
insert into user(name,age) values(#{name},#{age }) 

</insert> 

<select id="getUser" resultlype="User" 

parameterType-"java.lang.String" > 

select * from user where name=#{name} 

</select> 

</mapper> 
C4) 测试 。 

至 此 ， 我 们 已 经 完成 了 Spring 与 MyBatis 的 整合 ， 我 们 发 现 ， 对 于 
MyBatis 方 面 的 配置 文件 ， 除 了 将 dataSource 配 置 移 到 Spring 配 置 文件 中 
管理 外 ， 并 没有 太 多 变化 ， 而 在 Spring 的 配置 文件 中 又 增加 了 用 于 处 理 
MyBatis 的 两 个 bean。 

Spring 整合 MyBatis 的 优势 主要 在 于 使 用 上 ， 我 们 来 看 看 Spring 中 使 
用 MyBatis 的 用 法 。 

public class UserServiceTest { 

public static void main(String[] args) 1 
ApplicationContext context = new 
ClassPathXmlApplicationContext("test/ mybatis/ 


applicationContext.xml"); 


UserMapper userDao = 
(UserMapper)context.getBean("userMapper"); 
System.out.printIn(userDao.getUser("1'")); 


j 

测试 中 我 们 看 到 ， 在 Spring 中 使 用 MyBatis 非常 方便 ， 用 户 甚至 无 
法 察觉 自己 正在 使 用 MyBatis， 而 这 一 切 相 对 于 独立 使 用 MyBatis 时 必 
须要 做 的 各 种 见 余 操作 来 说 无 非 是 大 大 简化 了 我 们 的 工作 量 。 





9.3 源码 分 析 


通过 Spring 整合 MyBatis 的 示例 ， 我 们 感受 到 了 Spring 为 用 户 更 加 快 
捷 地 进行 开发 所 做 的 努力 ， 开 发 人 员 的 工作 效率 由 此 得 到 了 显著 的 提 
升 。 但 是 ， 相 对 于 使 用 来 说 ， 我 们 更 想 知 道 其 背后 所 隐藏 的 秘密 ， 
Spring 整合 MyBatis 是 何如 实现 的 呢 ? 通过 分 析 整 合 示例 中 的 配置 文件 ， 
我 们 可 以 知道 配置 的 bean 其 实 是 成 树 状 结构 的 ， 而 在 树 的 最 顶层 是 类 
型 为 org.mybatis. Spring.SqlSessionFactoryBean 的 bean， 它 将 其 他 相关 
bean 组 闭 在 了 一 起 ， 那 么 ， 我 们 的 分 析 束 从 此 类 开始 。 

9.3.1 sqlSessionFactory 创 建 

通过 配置 文件 我 们 分 析 ， 对 于 配置 文件 的 读 取 解析 ，Spring 应 该 通 
过 org.mybatis.Spring.&nbsp;SqlSessionFactoryBean 封 装 了 MyBatis 中 的 实 
现 。 我 们 进入 这 个 类 ， 首 先 人 查看 这 个 类 的 层次 结构 ， 如 图 9-2 所 示 。 根 
据 这 个 类 的 层次 结构 找 出 我 们 感 兴 趣 的 两 个 接口 ， FactoryBean 和 


InitializingBean. 
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图 9-2 SqlSessionFactoryBean 类 的 层次 结构 图 


InitializingBean: 实现 此 接口 的 bean 会 在 初始 化 时 调用 其 
afterPropertiesSet 方 法 来 进行 bean 的 逻辑 初始 化 。 
FactoryBean: 一 旦 某 个 bean 实 现 次 接口 ， 那 么 通过 getBean 方 法 获 
取 bean 时 其 实 是 获取 此 类 的 getObjectO 返 回 的 实例 。 
我 们 首先 以 InitializingBean 接 口 的 afterPropertiesSet() 方 法 作为 突破 
Filo 
1. SqlSessionFactoryBean 的 初始 化 
查看 org.mybatis.Spring.SqlSessionFactoryBean 类 型 的 bean 在 初始 化 
时 做 了 哪些 逻辑 实现 。 
public void afterPropertiesSet() throws Exception { 
notNull(dataSource, "Property 'dataSource' is required"); 
notNull(sqlSessionFactoryBuilder, "Property 
'sqlSessionFactory Builder' is required"); 
this.sqlSessionFactory = buildSqlSessionFactory(); 
j 
很 显然 ， 此 函数 主要 目的 就 是 对 于 sqlSessionFactory 的 初始 化 ， 
过 之 前 展示 的 独立 使 用 MyBatis 的 示例 ， 我 们 了 解 到 E oe. 
所 有 MyBatis 功 能 的 基础 。 
protected SqlSessionFactory buildSqlSessionFactory() throws 


IOException { 
Configuration configuration; 
XMLConfigBuilder xmlConfigBuilder = null; 
if (this.configLocation != null) { 
xmlConfigBuilder = new 
XMLConfigBuilder(this.configLocation.getInputStream(), null, 
this.configurationProperties); 
configuration = xmlConfigBuilder.getConfiguration(); 
} else { 
if (this. logger.isDebugEnabled()) { 
this.logger.debug("Property 'configLocation' not specified, using 
default MyBatis 
Configuration"); 
j 
configuration = new Configuration(); 
configuration.setVariables(this.configurationProperties); 
j 
if (this.objectFactory !- null) 1 
configuration.setObjectFactory(this.objectFactory); 
j 
if (this.objectWrapperFactory !- null) 1 


configuration.setObjectWrapperFactory(this.objectWrapperFactory); 
j 
if (hasLength(this.typeAliasesPackage)) 1 
String[] typeAliasPackageArray = 
tokenizeToStringArray(this.typeAliasesPackage, 


ConfigurableApplicationContext.CONFIG LOCATION DELIMITERS); 
for (String packageToScan : typeAliasPackageArray) 1 


configuration.getTypeAliasRegistry().registerA liases(packageToScan, 
typeAliasesSuperType == null ? Object.class : 
typeAliasesSuperType); 
if (this. logger.isDebugEnabled()) { 
this.logger.debug("Scanned package: " + packageToScan + ” 
for aliases"); 


} 


} 
if ('isEmpty(this.typeAliases)) { 
for (Class<?> typeAlias : this.typeAliases) 1 
configuration.get TypeAliasRegistry().registerAlias(typeAlias); 
if (this.logger.isDebugEnabled()) { 
this.logger.debug( Registered type alias: " + typeAlias + """); 


j 
if ('isEmpty(this.plugins)) 1 
for (Interceptor plugin : this.plugins) { 
configuration.addInterceptor(plugin); 
if (this.logger.isDebugEnabled()) 1 
this.logger.debug(" Registered plugin: ' + plugin + ””); 


} 
if (hasLength(this.typeHandlersPackage)) { 
String[] typeHandlersPackageArray = 
tokenizeToStringArray(this.typeHandlersPackage, 


ConfigurableApplicationContext.CONFIG LOCATION DELIMITERS); 
for (String packageToScan : typeHandlersPackageArray) { 
configuration.getTypeHandlerRegistry().register(packageToScan); 
if (this.logger.isDebugEnabled()) 1 
this.logger.debug(" Scanned package: " + packageToScan + ” 
for type handlers"); 
j 


j 
if ('isEmpty(this.typeHandlers)) 1 
for (TypeHandler<?> typeHandler : this.typeHandlers) ( 
configuration.getTypeHandlerRegistry().register(typeHandler); 
if (this.logger.isDebugEnabled()) 1 
this.logger.debug(" Registered type handler: " + typeHandler + 


if (xmlConfigBuilder != null) 1 


try 1 
xmlConfigBuilder.parse(); 


if (this.logger.isDebugEnabled()) { 
this.logger.debug(""Parsed configuration file: '" + 
this.configLocation + """); 
} 
} catch (Exception ex) { 


throw new NestedIOException("Failed to parse config resource: ' 


Y 


+ this. 
configLocation, ex); 
} finally { 
ErrorContext.instance().reset(); 
} 
} 


if (this.transactionFactory == null) { 
this.transactionFactory = new SpringManagedTransactionFactory(); 
} 
Environment environment = new Environment(this.environment, 
this.transactionFactory, 
this.dataSource); 
configuration.setEnvironment(environment); 
if (this.databaseIdProvider != null) { 
try { 


configuration.setDatabaseld(this.databaseIdProvider.getDatabaseld 
(this.dataSource)); 
} catch (SQLException e) { 
throw new NestedIOException("Failed getting a databaseld", e); 


} 
if (!isEmpty(this.mapperLocations)) { 
for (Resource mapperLocation : this.mapperLocations) { 
if (mapperLocation == null) { 
continue; 
} 
try { 
XMLMapperBuilder xmlMapperBuilder = new 
XMLMapperBuilder(mapperLocation. 
getInputStream(), 
configuration, mapperLocation.toString(), 
configuration.getSqlFragments()); 
xmlMapperBuilder.parse(); 
} catch (Exception e) { 
+", e); 
throw new NestedIOException("Failed to parse mapping 
resource: " + mapperLocation 
} finally { 
ErrorContext.instance().reset(); 
} 
if (this.logger.isDebugEnabled()) { 


this.logger.debug("Parsed mapper file: ' + mapperLocation + 


} else { 
if (this. logger.isDebugEnabled()) { 


this.logger.debug("Property 'mapperLocations' was not specified or 
no matching 
resources found"); 
} 
} 
return this.sqlSessionFactoryBuilder.build(configuration); 
} 
从 函数 中 可 以 看 到 ， 尽 管 我 们 还 是 习惯 于 将 MyBatis 的 配置 与 Spring 
的 配置 独立 出 来 ， 但 是 ， 这 并 不 代表 Spring 中 的 配置 不 支持 直接 配置 。 
也 就 是 说 ， 在 上 面 提供 的 示例 中 ， 你 完全 可 以 取消 配置 中 的 
configLocation 属 性 ， 而 把 其 中 的 属性 直接 写 在 SqlSessionFactoryBean 
中 。 


<bean id="sqlSessionFactory" 





class="org.mybatis.Spring.SqlSessionFactoryBean"> 
<property name="configLocation" 
value="classpath:test/mybatis/MyBatis- Configuration. 
xml"></property> 
<property name-"dataSource" ref="dataSource" /> 
<property name-"typeAliasesPackage" value="aaaaa"/> 
</bean> 
从 这 个 函数 中 可 以 得 知 ， 配 置 文件 还 可 以 支持 其 他 多 种 属性 的 配 
置 ， 如 configLocation、objectFactory、objectWrapperFactory、 
typeAliasesPackage、typeAliases、typeHandlersPackage、plugins、 
typeHandlers、transactionFactory、databaseldProvider、 


mapperLocations 。 


其 实 ， 如 果 只 按照 常用 的 配置 ， 那 么 我 们 只 需要 在 函数 最 开始 按照 





如 下 方式 处 理 configuration: 

xmlConfigBuilder = new 
XMLConfigBuilder(this.configLocation.getInputStream(), null, 

this.configurationProperties); 

configuration = xmlConfigBuilder.getConfiguration(); 

根据 configLocation 构 造 XMLConfigBuilder 并 进行 解析 ， 但 是 ， 为 了 
体现 Spring 更 强大 的 兼容 性 ，Spring 还 整合 了 MyBatis 中 其 他 属性 的 注 
入 ， 并 通过 实例 configuration 来 承载 每 一 步 所 获取 的 信息 并 最 终 使 用 
sqlSessionFactoryBuilder 实例 根据 解析 到 的 configuration 创建 
SqlSessionFactory 实 例 。 

2. 获取 SqlSessionFactoryBean 实 例 

由 于 SqlSessionFactoryBean 实 现 了 FactoryBean 接 口 ， 所 以 当 通 过 
getBean 方 法 获取 对 应 实例 时 ， 其 实 是 获取 该 类 的 getObject() E 240 [Fl If 
实例 ， 也 就 是 获取 初始 化 后 的 sqlSession Factory 属 性 。 

public SqlSessionFactory getObject() throws Exception { 





if (this.sqlSessionFactory == null) { 
afterPropertiesSet(); 
} 


return this.sqlSessionFactory; 


} 


9.3.2 MapperEactoryvBean 上 的 创建 


为 了 使 用 MyBatis He, ANPP EN Spring 配置 文件 提供 了 两 个 
bean， 除 了 之 前 分 析 的 SqlSssionFactoryBean 类 型 的 bean 以 外 ， 还 有 一 个 
是 MapperFactoryBean 类 型 的 bean。 

结合 两 个 测试 用 例 综合 分 析 ， 对 于 单独 使 用 MyBatis 的 时 候 调 用 数 
据 库 接口 的 方式 是 : 





UserMapper userMapper = sqlSession.getMapper(UserMapper.class); 

而 在 这 一 过 程 中 ， 其 实 是 MyBatis 在 获取 映射 的 过 程 中 根据 配置 信 
A 7JUserMapper 类 型 动态 创建 了 代理 类 。 而 对 于 Spring 的 创建 方式 : 

UserMapper userMapper = 
(UserMapper)context.getBean("userMapper"); 

Spring 中 获取 的 名 为 userMapper 的 bean， 其 实 是 与 单独 使 用 MyBatis 
完成 了 一 样 的 功能 ， 那 么 我 们 可 以 推 关 ， 在 bean 的 创建 过 程 中 一 定 是 
使 用 了 MyBatis 中 的 原生 方法 sqlSession.getMapper(UserMapper.class) 进 
行 了 再 一 次 封装 。 结 合 配 置 文 件 ， 我 们 把 分 析 目 标 转 问 
org.mybatis.Spring.mapper. MapperFactoryBean， 初 步 推测 其 中 的 逻辑 应 
该 在 此 类 中 实现 。 同 样 ， 还 是 首先 查看 的 类 层次 结构 图 
MapperFactoryBean， 如 图 9-3 所 示 。 
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图 9-3 MapperFactoryBean 类 的 层次 结构 图 


同样 ， 在 实现 的 接口 中 发 现 了 我 们 感 兴趣 的 两 个 接口 
InitializingBean 与 FactoryBean。 我 们 的 分 析 还 是 从 bean 的 初始 化 开始 。 

1. MapperFactoryBean 的 初始 化 

为 实现 了 InitializingBean 接 口 ，Spring 会 保证 在 bean 初 始 化 时 首先 
调用 afterPropertiesSet 方 法 来 完成 其 初始 化 逻辑 。 仍 踪 父 类 ， 发 现 
afterPropertiesSet 方 法 是 在 DaoSupport 类 中 实现 ， 代 码 如 下 : 


public final void afterPropertiesSet() throws IllegalArgumentException, 
Beanlnitialization 
Exception 1 
// Let abstract subclasses check their configuration. 
checkDaoConfig(); 
// Let concrete implementations initialize themselves. 
try { 
initDao(); 
j 
catch (Exception ex) 1 
throw new BeanlnitializationException("Initialization of DAO 
failed", ex); 
j 
j 
但 从 函数 名 称 来 看 我 们 大 体 推 测 ，MapperFactoryBean 的 初始 化 包 
括 对 DAO 配 置 的 验证 以 及 对 DAO 的 初始 工作 ， 其 中 initDao0 方 法 是 模板 
方法 ， 设 计 为 留 给 子 类 做 进一步 逻辑 处 理 。 而 checkDaoConfig() 才 是 我 
们 分 析 的 重点 。 
@Override 
protected void checkDaoConfig() { 
super.checkDaoConfig(); 
notNull(this.mapperlInterface, "Property 'mapperInterface' is 
required"); 
Configuration configuration = getSqlSession().getConfiguration(); 
if (this.addToConfig && 
!configuration.hasMapper(this.mapperInterface)) { 


try { 


configuration.addMapper(this.mapperInterface); 
} catch (Throwable t) { 
logger.error("Error while adding the mapper '" + 


WY 


this.mapperlInterface + "' to 

configuration.", t); 

throw new Illegal ArgumentException(t); 
) finally { 


ErrorContext.instance().reset(); 


j 
super.checkDaoConfig() 在 SqlSessionDaoSupport 类 中 实现 ， 代 码 如 
i 
protected void checkDaoConfig() { 
notNull(this.sqlSession, "Property 'sqlSessionFactory' or 
'sqlSessionTemplate' are 
required"); 
j 
结合 代码 我 们 了 解 到 对 于 DAO 配 置 的 验证 ，Spring 做 了 以 下 几 个 方 
面 的 工作 。 
父 类 中 对 于 sqlSession 不 为 空 的 验证 。 
sqlSession 作 为 根据 接口 创建 映射 器 代理 的 接触 类 一 定 不 可 以 为 
空 ， 而 sqlSession 的 初始 化 工作 是 在 设 定 其 sqlSessionFactory 属 性 时 完成 
的 。 


public void setSqlSessionFactory(SqlSessionFactory sqlSessionFactory) 





if (!this.externalSqlSession) { 


this.sqlSession = new SqlSessionTemplate(sqlSessionFactory); 


} 
也 就 是 次， 对 于 下 面 的 配置 如 果 包 略 了 对 于 sqlSessionFactory 属 性 
的 设置 ， 那 么 在 此 时 就 会 被 检测 出 来 。 


<bean id="userMapper" 





class="org.mybatis.Spring.mapper.MapperFactoryBean"> 

<property name-"mapperlnterface" 
value="test.mybatis.dao.UserMapper"></property> 

<property name="sqlSessionFactory" ref="sqlSessionFactory"> 
</property> 

</bean> 

映射 接口 的 验证 。 

接口 是 映射 器 的 基础 ，sqlSession 会 根据 接口 动态 创建 相应 的 代理 
类 ， 上 所 以 接口 必 不 可 少 。 

映射 文件 存在 性 验证 。 

对 于 函数 前 半 部 分 的 验证 我 们 都 很 容易 理解 ， 无 非 是 对 配置 文件 中 
的 属性 是 人 否 存 在 做 验证 ， 但 是 后 面部 分 是 完成 了 什么 方面 的 验证 呢 ? 如 
果 读 者 读 过 MyBatis 源码 ， 你 就 会 知道 ， 在 MyBatis 实 现 过 程 中 并 没有 
手动 调用 configuration.addMapper 方 法 ， 而 是 在 映射 文件 读 取 过 程 中 一 旦 
解析 到 如 <mapper namespace="Mapper.UserMapper"> ， 便 会 自动 进行 类 
ABT AEA. ASA, Spring 中 为 什么 会 把 这 个 功能 单独 拿 出 来 放 在 验 
WEE? 这 是 不 是 多 此 一 举 呢 ? 

在 上 面 的 函数 中 ，configuration.addMapper(this.mapperInterface) 其 实 
Lek UserMapper 注册 到 映射 类 型 中 ， 如 果 你 可 以 保证 这 个 接口 一 定 
存在 对 应 的 映射 文件 ， 那 么 其 实 这 个 验证 并 没有 必要 。 但 是 ， 由 于 这 个 
是 我 们 自行 决定 的 配置 ， 无 法 保证 这 里 配置 的 接口 一 定 存 在 对 应 的 映射 
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文件 ， 所 以 这 里 非常 有 必要 进行 验证 。 在 执行 此 代码 的 时 候 ，MyBatis 
会 检查 欣 入 的 映 冉 接口 是 否 存 在 对 应 的 映 冉 文 件 ， 如 果 没 有 回 抛 出 异 
常 ，Spring 正 是 在 用 这 种 方式 来 完成 接口 对 应 的 映射 文件 存在 性 验证 。 

2. 获取 MapperFactoryBean 的 实例 

由 于 MapperFactoryBean 实 现 了 FactoryBean 接 口 ， 所 以 当 通 过 
getBean 方 法 获取 对 应 实例 的 时 候 其 实 是 获取 该 类 的 getObject0 函 数 返 回 
的 实例 。 

public T getObject() throws Exception { 














return getSqlSession().getMapper(this.mapperInterface); 
} 
这 段 代码 正 是 我 们 在 提供 MyBatis 独立 使 用 的 时 候 的 一 个 代码 调 
用 。Spring 通过 FactoryBean 进 行 了 封装 。 


9.3.3 MapperScannerConfigurer 


我 们 在 applicationContext.xml 中 配置 了 userMapper 供 需要 时 使 用 。 但 
如 果 需 要 用 到 的 映射 器 较 多 的 话 ， 米 用 这 种 配置 方式 就 显得 很 低 效 。 为 
了 解决 这 个 问题 ， 我 们 可 以 使 用 MapperScanner Configurer, EEH 
定 的 包 ， 自 动 帮 我 们 成 批 地 创建 映射 器 。 这 样 一 来 ， 就 能 大 大 减少 配置 
的 工作 量 ， 比 如 我 们 将 applicationContext.xml 文 件 中 的 配置 改 成 如 下 : 


<?xml version="1.0" encoding="UTF-8"?> 











«beans xmlns="http://www.Springframework.org/schema/beans" 


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www.Springframework. 
org/schema/beans/Spring-beans-3.0.xsd"> 


<bean id="dataSource" 


class="org.apache.commons.dbcp.BasicDataSource"> 
<property name="driverClassName" 
value="com.mysql.jdbc.Driver"></property> 
<property name="url" 
value="jdbc:mysal://localhost:3306/lexueba?useUnicode= 
true&amp;characterEncoding-UTF- 
8&amp;zeroDateTimeBehavior=convertToNull"></property> 


<property name-"username" value="root"></property> 


<property name-"password" value="haojia0421xixi"></property> 


<property name-"maxActive" value="100"></property> 
<property name="maxlIdle" value="30"></property> 


<property name="maxWait" value="500"></property> 


<property name-"defaultAutoCommit" value="true"></property> 


</bean> 

<bean id="sqlSessionFactory" 
class="org.mybatis.Spring.SqlSessionFactoryBean"> 

<property name="configLocation" 
value="classpath:test/mybatis/MyBatis- Configuration. 
xml"></property> 
<property name-"dataSource" ref="dataSource" /> 
<property name-"typeAliasesPackage" value="aaaaa"/> 
</bean> 
<!-- 注释 挥 原 有 代码 

<bean id="userMapper" 

class="org.mybatis. Spring.mapper.MapperFactoryBean"> 
<property name-"mapperlInterface" 


value="test.mybatis.dao. UserMapper"></property> 


<property name="sqlSessionFactory" ref="sqlSessionFactory"> 
</property> 
</bean> 
--> 
<bean 
class="org.mybatis.Spring.mapper.MapperScannerConfigurer"> 
<property name="basePackage" value="test.mybatis.dao" /> 
</bean> 
</beans> 
在 上 面 的 配置 中 ， 我 们 屏蔽 掉 了 最 原始 的 代码 〈userMapper 的 创 
建 ) 而 增加 了 MapperScannerConfigurer 的 配置 ，basePackage 属性 是 让 
你 为 映射 器 接口 文件 设置 基本 的 包 路 径 。 你 可 以 使 用 分 号 或 去 号 作为 分 
隅 符 设 置 多 于 一 个 的 包 路 径 。 每 个 映射 器 将 会 在 指定 的 包 路 径 中 递归 地 
被 搜索 到 。 被 发 现 的 映射 器 将 会 使 用 Spring 对 上 自动 侦 测 组 件 默认 的 命名 
策略 来 命名 。 也 就 是 说 ， 如 果 没 有 发 现 注 解 ， 它 就 会 使 用 映射 器 的 非 大 
写 的 非 完 全 限定 类 名 。 但 是 如 果 发 现 了 @Component 或 JSR- 
330@Named 注解 ， 它 会 获取 名 称 。 
通过 上 面 的 配置 ， Spring 就 会 帮助 我 们 对 test. mybatis.dao 下 面 的 所 
有 接口 进行 目 动 的 注入 ， 而 不 需要 为 每 个 接口 重复 在 Spring 配置 文件 中 
进行 声明 了 。 那 么 ， 这 个 功能 又 是 如 何 做 到 的 呢 ? MapperScanner 
Configurer 中 又 有 哪些 核心 操作 呢 ? 同样 ， 首 先 查 看 类 的 层次 结构 图 ， 
如 图 9-4 所 示 。 
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图 9-4 MapperScannerConfigurer 类 的 层次 结构 图 


我 们 又 看 到 了 令 人 感 兴趣 的 接口 InitializingBean， 蕊 上 查找 类 的 
afterPropertiesSet 方法 来 看 看 类 的 初始 化 逻辑 。 

public void afterPropertiesSet() throws Exception { 

notNull(this.basePackage, "Property 'basePackage' is required"); 

} 

很 晃 憾 ， 分 析 并 没有 想 我 们 之 前 那样 顺利 ，afterPropertiesSet() 方 法 
除了 一 句 对 basePackage 属 性 的 验证 代码 外 并 没有 太 多 的 逻辑 实现 。 好 
吧 ， 让 我 们 回 过 头 再 次 查看 MapperScanner Configurer 类 层次 结构 图 中 
感 兴趣 的 接口 。 于 是 ， 我 们 发 现 了 BeanDefinitionRegistryPostProcessor 与 
BeanFactoryPostProcessor，Spring 在 初始 化 的 过 程 中 同样 会 保证 这 两 个 
接口 的 调用 。 

首先 查看 MapperScannerConfigurer 类 中 对 于 
BeanFactoryPostProcessor 接 口 的 实现 : 





public void postProcessBeanFactory(ConfigurableListableBeanFactory 
beanFactory) { 
// left intentionally blank 


没有 任何 逻辑 实现 ， 只 能 说 明 我 们 找 错 地方 了 ， 继 续 找 ， 碍 看 
MapperScannerConfigurer 类 中 对 于 BeanDefinitionRegistryPostProcessor 接 
口 的 实现 。 
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry 
registry) throws 
BeansException { 
if (this.processPropertyPlaceHolders) { 
processPropertyPlaceHolders(); 
} 
ClassPathMapperScanner scanner = new 
ClassPathMapperScanner(registry); 
scanner.setAddToConfig(this.addToConfig); 
scanner.setAnnotationClass(this.annotationClass); 
scanner.setMarkerInterface(this.markerInterface); 
scanner.setSqlSessionFactory(this.sqlSessionFactory); 


scanner.setSqlSessionTemplate(this.sqlSessionTemplate); 


scanner.setSqlSessionFactoryBeanNamer(this.sqlSessionFactoryBeanName); 


scanner.setSqlSessionTemplateBeanName(this.sqlSessionTemplateBeanNam«e 
scanner.setResourceLoader(this.applicationContext); 
scanner.setBeanNameGenerator(this.nameGenerator); 
scanner.registerFilters(); 
scanner.scan(StringUtils.tokenizeToStringArray(this.basePackage, 
Configurable 
ApplicationContext.CONFIG LOCATION DELIMITERS)); 





Bingo! 这 次 找 对 地 方 了 。 大 致 看 一 下 代码 实现 ， 正 是 完成 了 对 指 
定 路 径 扫 描 的 逻辑 。 那 么 ， 我 们 就 以 此 为 入 口 ， 详 细 地 分 析 
MapperScannerConfigurer 所 提供 的 逻辑 实现 。 
1. processPropertyPlaceHolders 属 性 的 处 理 
首先 ， 难 题 就 是 processPropertyPlaceHolders 属 性 的 处 理 。 或 许 读 者 
并 未 过 多 接触 此 属性 ， 我 们 只 能 查看 processPropertyPlaceHolders() 函 数 
来 反 推 此 属性 所 代表 的 功能 。 
/* 
* BeanDefinitionRegistries are called early in application startup, 
before 
* BeanFactoryPostProcessors. This means that 
PropertyResourceConfigurers will not have been 
* loaded and any property substitution of this class' properties will 
fail. To avoid 
this, find 
* any PropertyResourceConfigurers defined in the context and run 
them on this class' bean 
* definition. Then update the values. 
Ti 
private void processPropertyPlaceHolders() 1 
Map<String, PropertyResourceConfigurer> prcs = 
applicationContext.getBeansOfT ype 
(PropertyResourceConfigurer.class); 
if (!prcs.isEmpty() && applicationContext instanceof 
GenericApplicationContext) { 
BeanDefinition mapperScannerBean = 


((GenericApplicationContext) applicationContext) 


.getBeanFactory().getBeanDefinition(beanName); 

// PropertyResourceConfigurer does not expose any methods to 
explicitly perform 

// property placeholder substitution. Instead, create a BeanFactory 
that just 

// contains this mapper scanner and post process the factory. 

DefaultListableBeanFactory factory = new 
DefaultListableBeanFactory(); 

factory.registerBeanDefinition(beanName, mapperScannerBean); 

for (PropertyResourceConfigurer prc : prcs.values()) 1 

prc.postProcessBeanFactory(factory); 

} 

Property Values values = 
mapperScannerBean.getProperty V alues(); 

this.basePackage = updateProperty Value("basePackage", values); 

this.sqlSessionFactoryBeanName = 
updateProperty Value(" sqlSessionFactoryBeanName", 

values); 

this.sqlSessionTemplateBeanName = 
updateProperty Value("sqlSessionTemplateBeanName", 


values); 


} 

不 知 读者 是 否 司 出 了 此 函数 的 作用 呢 ? 或 许 此 函数 的 说 明 会 给 我 们 
一 些 提示 : BeanDefinitionRegistries 会 在 应 用 启动 的 时 候 调用 ， 并 且 会 早 
于 BeanFactoryPostProcessors 的 调用 ， 这 就 意味 着 
PropertyResourceConfigurers 还 没有 被 加 载 所 有 对 于 属性 文件 的 引用 将 会 





失效 。 为 避免 此 种 情况 发 生 ， 此 方法 手动 地 找 出 定义 的 
PropertyResourceConfigurers 并 进行 提前 调用 以 保证 对 于 属性 的 引用 可 以 
正常 工作 。 

我 想 读者 已 经 有 所 感悟， 结合 之 前 讲 过 的 
PropertyResourceConfigurer 的 用 法 ， 举 例 说 明 一 下 ， 如 要 创建 配置 文件 
如 test.properties， 并 添加 属性 对 : 

basePackage=test.mybatis.dao 

然后 在 Spring 配置 文件 中 加 入 属性 文件 解析 器 : 

<bean id="mesHandler" 
class="org.Springframework.beans.factory.config.Property Placeholder 

Configurer"> 

<property name="locations"> 
<list> 
<value>config/test.properties</value> 
</list> 
</property> 

</bean> 

修改 MapperScannerConfigurer 类 型 的 bean 的 定义 : 

<bean class="org.mybatis.Spring.mapper.MapperScannerConfigurer"> 

<property name="basePackage" value="${basePackage}" /> 
</bean> 

此 时 你 会 及 现 ， 这 个 配置 并 没有 达到 预期 的 效果 ， 因 为 在 解析 
${basePackage} 的 时 候 PropertyPlaceholderConfigurer 还 没有 被 调用 ， 也 就 
是 属性 文件 中 的 属性 还 没有 加 载 至 内 存 中 ， Spring 还 不 能 直接 使 用 它 。 
为 了 解决 这 个 问题 ，Spring 提 供 了 processPropertyPlaceHolders 属 性 ， 你 
需要 这 样 配置 MapperScannerConfigurer 类 型 的 bean 。 


<bean class="org.mybatis.Spring.mapper.MapperScannerConfigurer"> 





<property name-"basePackage" value="test.mybatis.dao" /> 
<property name="processPropertyPlaceHolders" value="true" /> 

</bean> 

通过 processPropertyPlaceHolders 属 性 的 配置 ， 将 程序 引入 我 们 正在 
分 析 的 processProperty PlaceHolders 函数 中 来 完成 属性 文件 的 加 载 。 至 
此 ， 我 们 终于 理 清 了 这 个 属性 的 作用 ， 再 次 回顾 这 个 函数 所 做 的 事情 。 

(1) 找到 所 有 已 经 注册 的 PropertyResourceConfigurer 类 型 的 bean。 
(2) 模拟 Spring 中 的 环境 来 用 处 理 占 。 这 里 通过 使 用 new 

DefaultListableBeanFactory() 来 模拟 Spring 中 的 环境 《完成 处 理 喜 的 调用 
后 便 失 效 ) ， 将 映射 的 bean, tiz MapperScanner Configurer 类 型 
bean 注 册 到 环境 中 来 进行 后 理 器 的 调用 ， 处 理 器 
PropertyPlaceholderConfigurer 调 用 完成 的 功能 ， 即 找 出 所 有 bean 中 应 用 
属性 文件 的 变量 并 玲 换 。 也 束 是 说 ， 在 处 理 器 调用 后 ， 模 拟 环 境 中 模拟 
的 MapperScannerConfigurer 类 型 的 bean 如 果 有 引入 属性 文件 中 的 属性 那 
么 已 经 被 奉 换 了 ， 这 时 ， 再 将 模拟 bean 中 相关 的 属性 提取 出 来 应 用 在 真 
实 的 bean 中 。 

2. 根据 配置 属性 生成 过 滤器 

在 postProcessBeanDefinitionRegistry 方 法 中 可 以 看 到 ， 配 置 中 支持 
很 多 属性 的 设 定 ， 但 是 我 们 感 兴趣 的 或 者 说 影响 扫描 结果 的 并 不 多 ， 属 
性 设置 后 通过 在 scanner.registerFiltersO 代 码 中 生成 对 应 的 过 滤器 来 控制 
扫描 结果 。 

public void registerFilters() { 











boolean acceptAllInterfaces = true; 
/对 于 annotationClass 属 性 的 处 理 
if (this.annotationClass != null) { 
addIncludeFilter(new AnnotationTypeFilter(this.annotationClass)); 


acceptAllInterfaces = false; 


} 
/对 于 markerInterface 属 性 的 处 理 
if (this.markerInterface != null) { 


addIncludeFilter(new AssignableTypeFilter(this.markerInterface) 


@Override 
protected boolean matchClassName(String className) { 
return false; 
i 
y 
acceptAllInterfaces = false; 
} 
if (acceptAll Interfaces) { 
// default include filter that accepts all classes 
addIncludeFilter(new TypeFilter() { 
public boolean match(MetadataReader metadataReader, 
MetadataReaderFactory metadata 
ReaderFactory) throws IOException 1 


return true; 


y 
j 
/不 扫描 package-info.java 文 件 
addExcludeFilter(new TypeFilter() { 
public boolean match(MetadataReader metadataReader, 
MetadataReaderFactory metadata 
ReaderFactory) throws IOException 1 


String className = 
metadataReader.getClassMetadata().getClassName(); 
return className.endsWith("package-info"); 
} 
y 
} 
代码 中 得 知 ， 根 据 之 前 属性 的 配置 生成 了 对 应 的 过 滤器 。 
(1) annotationClass 属 性 处 理 。 

如 采 annotationClass 不 为 空 ， 表 示 用 户 设置 了 此 属性 ， 那 么 就 要 根 
据 此 属性 生成 过 滤器 以 保证 达到 用 户 想 要 的 效果 ， 而 封装 此 属性 的 过 滤 
aritz AnnotationTypeFilter. Annotation TypeFilter 保 证 在 扫描 对 应 Java 
文件 时 只 接受 标记 有 注解 为 annotationClass 的 接口 。 

(2) markerInterface 属 性 处 理 。 

如 有 果 markerInterface 不 为 空 ， 表 示 用 户 设 置 了 此 属性 ， 那 么 就 要 根 
据 此 属性 生成 过 滤器 以 保证 达到 用 户 想 要 的 效果 ， 而 封装 此 属性 的 过 渡 
器 就 是 实现 AssignableTypeFilter 接口 的 局 部 类 。 表 示 扫 描 过 程 中 只 有 实 
现 markerInterface 接 口 的 接口 才 会 被 接受 。 

(3) 全 局 默认 处 理 。 

在 上 面 两 个 属性 中 如 果 存 在 其 中 任何 属性 ，acceptAllInterfaces 的 值 
将 会 变 改变 ， 但 是 如 果 用 户 没 有 设 定 以 上 两 个 属性 ， 那 么 ，Spring 会 为 
我 们 增加 一 个 默认 的 过 小 器 实现 TypeFilter 接 口 的 局 部 类 ， 则 在 接受 所 
有 接口 文件 。 

(4) package-info.java 处 理 。 

对 于 命名 为 package-info 的 Java 文 件 ， 默 认 不 作为 逻辑 实现 接口 ， 
将 其 排除 掉 ， 使 用 TypeFilter 接 口 的 局 部 类 实现 match 方 法 。 

从 上 面 的 函数 我 们 看 出 ， 控 制 扫描 文件 Spring 通 过 不 同 的 过 滤 右 完 
成 ， 这 些 定义 的 过 滤器 记录 在 了 includeFilters 和 excludeFilters 属 性 中 。 


public void addIncludeFilter(TypeFilter includeFilter) { 
this.includeFilters.add(includeFilter); 
} 
public void addExcludeFilter(TypeFilter excludeFilter) { 
this.excludeFilters.add(0, excludeFilter); 
} 
至 于 过 滤器 为 什么 会 在 扫描 过 程 中 起 作用 ， 我 们 在 讲解 扫描 实现 时 
候 再 继续 深入 研究 。 
3. 扫描 Java 文 件 
设置 了 相关 属性 以 及 生成 了 对 应 的 过 滤器 后 便 可 以 进行 文件 的 扫 拉 
了 ， 扫 描 工 作 是 由 ClassPathMapperScanner 类 型 的 实例 scanner 中 的 scan 方 
法 完成 的 。 
public int scan(String... basePackages) { 
int beanCountAtScanStart = this.registry.getBeanDefinitionCount(); 
doScan(basePackages); 
/如 果 配 置 了 includeAnnotationConfig， 则 注册 对 应 注解 的 处 理 器 以 
保证 注解 功能 的 正常 使 用 。 


if (this.includeAnnotationConfig) { 


AnnotationConfigUtils.register AnnotationConfigProcessors(this.registry); 
j 
return this.registry.getBeanDefinitionCount() - 
beanCountAtScanStart; 
j 
scan 是 个 全 局 方法 ， 扫 描 工 作 通 过 doScan(basePackages) 委 托 给 了 
doScan 方 法 ， 同 时 ， 还 包括 了 includeAnnotationConfig 属 性 的 处 理 ， 


AnnotationConfigUtils.registerAnnotation ConfigProcessors (this.registry) 代 


码 主 要 是 完成 对 于 注解 处 理 器 的 简单 注册 ， 比 如 
AutowiredAnnotationBeanPost Processor, 
RequiredAnnotationBeanPostProcessor=§, ix HAFRAIR, FTE A 
文件 扫描 功能 的 实现 。 
ClassPathMapperScanner.java 
public Set<BeanDefinitionHolder> doScan(String... basePackages) { 
Set<BeanDefinitionHolder> beanDefinitions = 
super.doScan(basePackages); 
if (beanDefinitions.isEmpty()) { 
/如 果 没 有 扫描 到 任何 文件 发 出 警告 
logger.warn("No MyBatis mapper was found in "+ 
Arrays.toString(basePackages) + ” 
package. Please check your configuration."); 
} else { 
for (BeanDefinitionHolder holder : beanDefinitions) { 
GenericBeanDefinition definition = (GenericBeanDefinition) 
holder.getBeanDefinition(); 
if (logger.isDebugEnabled()) 1 
logger.debug(" Creating MapperFactoryBean with name ”+ 
holder.getBeanName() 
+' and ' + definition.getBeanClassName() + " 
mapperlInterface"); 
j 
// 开 始 构 造 MapperFactoryBean 类 型 的 bean. 
definition.getPropertyValues().add("mapperInterface", 
definition.getBeanClassName()); 


definition.setBeanClass(MapperFactoryBean.class); 


definition.getProperty Values().add(" add ToConfig", 
this.add ToConfig); 
boolean explicitFactoryUsed - false; 
if (StringUtils.hasText(this.sqlSessionFactoryBeanName)) 1 
definition.getProperty Values().add(" sqlSessionFactory", new 
RuntimeBeanReference 
(this.sqlSessionFactoryBeanName)); 
explicitFactoryUsed = true; 
} else if (this.sqlSessionFactory !- null) { 
definition.getProperty Values().add(" sqlSessionFactory", 
this.sqlSessionFactory); 
explicitFactoryUsed - true; 
j 
if (StringUtils.hasText(this.sqlSessionTemplateBeanName)) { 
if (explicitFactoryUsed) 1 
logger.warn(" Cannot use both: sqlSessionTemplate and 
sqlSessionFactory together. 
sqlSessionFactory is ignored."); 
j 
definition.getProperty Values().add(" sqlSession Template", new 
RuntimeBeanReference 
(this.sqlSessionTemplateBeanName)); 
explicitFactoryUsed - true; 
} else if (this.sqlSessionTemplate != null) { 
if (explicitFactoryUsed) 1 
logger.warn(" Cannot use both: sqlSessionTemplate and 


sqlSessionFactory together. 


sqlSessionFactory is ignored."); 
} 
definition. getProperty Values().add(" sqlSessionTemplate", 
this.sqlSessionTemplate); 
explicitFactoryUsed = true; 
} 
if (lexplicitFactoryUsed) { 
if (logger.isDebugEnabled()) { 
logger.debug("Enabling autowire by type for 
MapperFactoryBean with name "+ 


holder.getBeanName() + "'."); 


definition.setAutowireMode(AbstractBeanDefinition.AUTOWIRE BY TYP: 
j 


j 

此 时 ， 虽 然 还 没有 完成 介绍 到 扫描 的 过 程 ， 但 是 我 们 也 应 该 理解 了 
Spring 中 对 于 上 自动 扫 摘 的 注册 ， 声 明 MapperScannerConfigurer 类 型 的 
bean 目的 是 不 需要 我 们 对 于 每 个 接口 都 注册 一 个 MapperFactoryBean 类 
型 的 对 应 的 beaan， 但 是 ， 不 在 配置 文件 中 注册 并 不 代表 这 个 bean 不 存 
在 ， 而 是 在 扫描 的 过 程 中 通过 编码 的 方式 动态 注册 。 实 现 过 程 我 们 在 上 
面 的 函数 中 可 以 看 得 非常 清楚 


protected Set<BeanDefinitionHolder> doScan(String... basePackages) { 











Assert.notEmpty(basePackages, "At least one base package must be 
specified"); 


Set<BeanDefinitionHolder> beanDefinitions = new LinkedHashSet 


<BeanDefinition 
Holder>(); 
for (String basePackage : basePackages) { 
/扫描 basePackage 路 径 下 java 文 件 
Set<BeanDefinition> candidates = 
findCandidateComponents(basePackage); 
for (BeanDefinition candidate : candidates) { 
/解析 scope 属 性 
ScopeMetadata scopeMetadata = 
this.scopeMetadataResolver.resolveScopeMetadata 
(candidate); 
candidate.setScope(scopeMetadata.getScopeName()); 
String beanName = 
this.beanNameGenerator.generateBeanName(candidate, 
this.registry); 
if (candidate instanceof AbstractBeanDefinition) { 


postProcessBeanDefinition((AbstractBeanDefinition) 


candidate, 
beanName); 
} 
if (candidate instanceof AnnotatedBeanDefinition) { 
/如 果 是 AnnotatedBeanDefinition 类 型 的 bean, 需 要 检测 下 
第 用 注解 如 : 


Primary、Lazy 等 
AnnotationConfigUtils.processCommonDefinitionAnnotations 


((AnnotatedBeanDefinition) candidate); 


/检测 当前 bean 是 否 已 经 注册 
if (checkCandidate(beanName, candidate)) { 
BeanDefinitionHolder definitionHolder = new 
BeanDefinitionHolder 
(candidate, beanName); 
/如 有 果 当 前 bean 是 用 于 生成 代理 的 bean 那 么 需要 进一步 处 
RE 


definitionHolder = 


AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata, 
definitionHolder, this.registry); 
beanDefinitions.add(definitionHolder); 


registerBeanDefinition(definitionHolder, this.registry); 


j 
return beanDefinitions; 
j 
public Set<BeanDefinition> findCandidateComponents(String 
basePackage) 1 
Set<BeanDefinition> candidates = new 
LinkedHashSet<BeanDefinition>(); 
try { 
String packageSearchPath = ResourcePatternResolver. 
CLASSPATH ALL URL. 
PREFIX + 


resolveBasePackage(basePackage) + "/" + this.resourcePattern; 


Resource[] resources = this.resourcePatternResolver.getResources 
(package 
SearchPath); 
boolean traceEnabled = logger.isTraceEnabled(); 
boolean debugEnabled = logger.isDebugEnabled(); 
for (Resource resource : resources) { 
if (traceEnabled) { 
logger.trace("Scanning " + resource); 
} 
if (resource.isReadable()) { 
try { 
MetadataReader metadataReader = 
this.metadataReaderFactory. 
getMetadataReader(resource); 
if (isCandidateComponent(metadataReader)) { 
ScannedGenericBeanDefinition sbd = new 
ScannedGenericBean 
Definition(metadataReader); 
sbd.setResource(resource); 
sbd.setSource(resource); 
if (isCandidateComponent(sbd)) { 
if (debugEnabled) { 
logger.debug("Identified candidate component 
class: " + resource); 
} 
candidates.add(sbd); 


else { 
if (debugEnabled) { 
logger.debug("Ignored because not a concrete 


top-level class: " + resource); 


j 
else { 
if (traceEnabled) { 
logger.trace(" Ignored because not matching any 


filter: " + resource); 


} 
catch (Throwable ex) { 
throw new BeanDefinitionStoreException( 


"Failed to read candidate component class: " + resource, ex); 


} 


else { 
if (traceEnabled) { 


logger.trace("Ignored because not readable: " + resource); 


catch (IOException ex) { 


throw new BeanDefinitionStoreException("IO failure during 
classpath 
scanning", ex); 
} 
return candidates; 
} 
findCandidateComponents 方法 根据 传 入 的 包 路 径 信息 并 结合 类 文件 
路 径 拼接 成 文件 的 绝对 路 径 ， 同 时 完成 了 文件 的 扫描 过 程 并 且 根 据 对 应 
的 文件 生成 了 对 应 的 bean ， 使 用 ScannedGenericBeanDefinition 类 型 的 
bean 承 载 信息 ，bean 中 只 记录 了 resource 和 source 信 息 。 这 里 ， 我 们 更 感 
兴趣 的 是 isCandidateComponent(metadataReadem， 此 名 代码 用 于 判断 当 
前 扫描 的 文件 是 否 符合 要 求 ， 而 我 们 之 前 注册 的 一 些 过 滤器 信息 也 正 是 
在 此 时 派 上 用 场 的 。 


protected boolean isCandidateComponent(MetadataReader 








metadataReader) throws IOException { 
for (TypeFilter tf : this.excludeFilters) { 
if (tf.match(metadataReader, this.metadataReaderFactory)) { 


return false; 


} 
for (TypeFilter tf : this.includeFilters) { 
if (tf.match(metadataReader, this.metadataReaderFactory)) 1 
AnnotationMetadata metadata = 
metadataReader.getAnnotationMetadata(); 
if (!Imetadata.isAnnotated(Profile.class.getName())) { 


return true; 


AnnotationAttributes profile = 
MetadataUtils.attributesFor(metadata, 
Profile.class); 
return 
this.environment.acceptsProfiles(profile.getStringArray(" value")); 
j 
j 
return false; 
j 
我 们 看 到 了 之 前 加 入 过 滤器 的 两 个 属性 excludeFilters. 
includeFilters， 并 且 知 道 对 应 的 文件 是 否 符 合 要 求 是 根据 过 滤器 中 的 
match 方 法 所 返回 的 信息 来 判断 的 ， 当 然 用 户 可 以 实现 并 注册 满足 上 自己 
业务 逻辑 的 过 滤器 来 控制 扫描 的 结果 ，metadataReader 中 有 你 过 滤 所 需 
要 的 全 部 文件 信息 。 至 此 ， 我 们 完成 了 文件 的 扫描 过 程 的 分 析 。 





Spring 声明 式 事务 让 我 们 从 复杂 的 事务 处 理 中 得 到 解脱 ， 使 我 们 再 
也 不 需要 去 处 理 获得 连接 、 关 闭 连 接 、 事 务 提交 和 回 深 等 操作 ， 再 也 不 
需要 在 与 事务 相关 的 方法 中 人 处理 大 量 的 try...catch...finally 代 人 码 。Spring 
中 事务 的 使 用 虽然 已 经 相对 简单 得 多 ， 但 是 ， 还 是 有 很 多 的 使 用 及 配置 
规则 ， 有 兴趣 的 读者 可 以 自己 查阅 相关 资料 进行 深入 研究 ， 这 里 只 列举 
出 最 常用 的 使 用 方法 。 
同样 ， 我 们 还 是 以 最 简单 的 示例 来 进行 直观 地 介绍 


10.1 JDBC 方 式 务 RARI 


C1) 创建 数据 表 结 构 。 
CREATE TABLE user ( 
id int(11) NOT NULL auto_increment, 
‘name' varchar(255) default NULL, 
‘age’ int(11) default NULL, 
'sex' varchar(255) default NULL, 
PRIMARY KEY (‘id’) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 
(20 创建 对 应 数据 表 的 PO。 
public class User { 
private int id; 
private String name; 
private int age; 
private String sex; 
/省 略 setyget 方 法 
} 
(30 创建 表 与 实体 间 的 映射 。 
public class UserRowMapper implements RowMapper { 
@Override 
public Object mapRow(ResultSet set, int index) throws 
SQLException { 
User person = new User(set.getInt("id"), set.getString(" name"), set 
.getInt("age"), set.getString("sex")); 


return person; 


} 
(4) 创建 数据 操作 接口 。 


@Transactional(propagation=Propagation.REQUIRED) 
public interface UserService { 
public void save(User user) throws Exception; 
} 
(5) 创建 数据 操作 接口 实现 类 。 
public class UserServiceImpl implements UserService { 
private JdbcTemplate jdbcTemplate; 
/ 设置 数据 源 
public void setDataSource(DataSource dataSource) { 
this.jdbcTemplate = new JdbcTemplate(dataSource); 
} 
public void save(User user) throws Exception { 
jdbcTemplate.update("insert into user(name,age,sex)values(?,?,?)", 
new Object[] { user.getName(), user.getAge(), 
user.getSex() }, new int[] { java.sql. Types. VARCHAR, 
java.sql. Types. INTEGER, java.sql. Types. VARCHAR J; 
NAMA, TNE A) ARS DUC AI m AF Bl BE e nn 


throw new RuntimeException("aa"); 





} 
(6) 创建 Spring 配置 文件 。 
<?xml version="1.0" encoding="UTF-8"?> 
«beans xmlIns="http://www.Springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:tx="http://www.Springframework.org/schema/tx" 
xmilns:context="http://www.Springframework.org/schema/context" 


xsi:schemaLocation=" 


http://www.Springframework.org/schema/beans 
http://www.Springframework. 
org/schema/beans/Spring-beans-2.5.xsd 
http://www.Springframework.org/schema/context 
http://www.Springframework. 
org/schema/context/Spring-context-2.5.xsd 
http://www.Springframework.org/schema/tx 
http://www.Springframework.org/ 
schema/tx/Spring-tx-2.5.xsd 
e. 
«tx:annotation-driven transaction-manager="transactionManager" 
/> 


<bean id="transactionManager" 


class-"org.Springframework.jdbc.datasource.DataSourceTransactionManager 
«property name-"dataSource" ref="dataSource" /> 
</bean> 
<!-- 配 置 数据 源 --> 
<bean id="dataSource" 
class-"org.apache.commons.dbcp.BasicDataSource" 
destroy-method="close"> 
<property name="driverClassName" 
value="com.mysql.jdbc.Driver" /> 
<property name="url" 
value="jdbc:mysql://localhost:3306/lexueba" /> 
<property name-"username" value="root" /> 


<property name="password" value="haojia0421xixi" /> 


<!-- 连 接 池 启动 时 的 初始 值 --> 
<property name="initialSize" value="1" /> 
<!-- 连 接 池 的 最 大 值 --> 
<property name-"maxActive" value="300" /> 
<!-- 最 大 空闲 值 . 当 经 过 一 个 高 峰 时 间 后 ， 连 接 池 可 以 慢 慢 将 已 
经 用 不 到 的 连接 慢 慢 释放 一 部 分 ， 一直 减 
少 到 maxIdle 为 止 --> 
<property name-"maxldle" value="2" /> 
<l- TAWE. SA E BU E BU TRER, EREA E FHA 
请 去 一 些 连 接 ， 以 免 洪 峰 来 时 来 不 及 申请 --> 
<property name-"minlIdle" value="1" /> 
</bean> 
<!-- 配 置业 务 bean: PersonServiceBean --> 
<bean id="userService" class="service.UserServiceImpl"> 
<!-- 向 属性 dataSource 注 入 数据 源 --> 
<property name-"dataSource" ref="dataSource"></property> 
</bean> 














</beans> 
C7) 测试 。 
public static void main(String[] args) throws Exception { 
ApplicationContext act = new 
ClassPathXmlApplicationContext("bean.xml"); 
UserService userService = (UserService) act.getBean("userService"); 
User user = new User(); 
user.setName(" 5% — ccc"); 
user.setAge(20); 


user.setSex(" 5j"); 


/ 保存 一 条 记录 
userService.save(user); 
} 

} 

上 面 的 测试 示例 中 ，UserServiceImpl 类 对 接口 UserService 中 的 save 
函数 的 实现 最 后 加 入 了 一 句 抛 出 异常 的 代码 : throw new 
RuntimeException("aa")。 当 注 挥 这 段 代 码 执 行 测 试 类 ， 那 么 会 看 到 数据 
被 成 功 的 保存 到 了 数据 库 中 ， 但 是 如 果 加 入 这 上 段 代码 时 再 次 运行 测试 
类 ， 发 现 此 处 的 操作 并 不 会 将 数据 保存 到 数据 库 中 。 

注意 默认 情况 下 Spring 中 的 事务 处 理 只 对 RuntimeException 方 法 进 
行 回 滚 ， 所 以 ， 如 果 此 处 将 RuntimeException 蔡 换 成 普通 的 Exception 不 
会 产生 回 滚 效 果 。 





10.2 事务 上 自 定 义 标 签 


对 于 Spring 中 事务 功能 的 代码 分 析 ， 我 们 首先 从 配置 文件 开始 入 
手 ， 在 配置 文件 中 有 这 样 一 个 配置 <tx:annotation-driven />。 可 以 说 此 
处 配置 是 事务 的 开关 ， 如 果 没 有 此 处 配置 ， 那 么 Spring 中 将 不 存在 事务 
的 功能 。 那 么 我 们 就 从 这 个 配置 开始 分 析 。 

根据 之 前 的 分 析 ， 我 们 因此 可 以 判断 ， 在 自 定义 标签 中 的 解析 过 程 
中 一 定 是 做 了 一 些 辅助 操作 ， 于 是 我 们 先 从 自 定 义 标 签 入 手 进行 分 析 。 

使 用 Eclipse 搜索 全 局 代码 ， 关 键 字 annotation-drive， 最 终 锁 定 类 
TxNamespaceHandler， 在 TxNamespaceHandler 中 的 init 方 法 中 : 

public void init() { 





registerBeanDefinitionParser("advice", new 
TxAdviceBeanDefinitionParser()); 


registerBeanDefinitionParser("annotation-driven", new 


AnnotationDrivenBean 
DefinitionParser()); 
registerBeanDefinitionParser("jta-transaction-manager", new 
Jta TransactionManagerBean 
DefinitionParser()); 
j 
根据 自 定 义 标签 的 使 用 规则 以 及 上 面 的 代码 ， 可 以 知道 ， 在 遇 到 诸 
如 <tx:annotation-driven 为 开头 的 配置 后 ，Spring 都 会 使 用 
AnnotationDrivenBeanDefinitionParser 类 的 parse 方 法 进行 解析 。 
public BeanDefinition parse(Element element, ParserContext 
parserContext) { 
String mode = element.getAttribute("Mmode"); 
if ('aspectj".equals(mode)) { 
// mode-"aspectj" 
registerTransactionAspect(element, parserContext); 
jelse 1 
// mode-"proxy" 
AopAutoProxyConfigurer.configureAutoProxyCreator(element, 
parserContext); 
j 
return null; 
j 
在 解析 中 存在 对 于 mode 属性 的 判断 ， 根 据 代码 ， 如 果 我 们 需要 使 
用 AspectJ 的 方式 进行 事务 切入 (Spring 中 的 事务 是 以 AOP 为 基础 
的 ) ， 那 么 可 以 使 用 这 样 的 配置 : 
<tx:annotation-driven transaction-manager- 'transactionManager" 


mode="aspectj" /> 


10.2.1 注册 InfrastructureAdvisorAutoProxyCreator 
我 们 以 默认 配置 为 例子 进行 分 析 ， 进 入 AopAutoProxyConfigurer 类 


的 configureAutoProxyCreator: 
public static void configureAutoProxyCreator(Element element, 


ParserContext parserContext) { 


AopNamespaceUtils.registerAutoProxyCreatorIf Necessary(parserContext, 
element); 
//'TRANSACTION ADVISOR, BEAN NAME 
="org.Springframework.transaction.config.internal 
TransactionAdvisor"; 
String txAdvisorBeanName = 
TransactionManagementConfigUtils. TRANSACTION - 
ADVISOR BEAN NAME; 
if (!parserContext. getRegistry().containsBeanDefinition 
(txAdvisorBean Name)) { 
Object eleSource = parserContext.extractSource(element); 
/创建 TransactionAttributeSource 的 bean 
RootBeanDefinition sourceDef = new RootBeanDefinition 
(Annotation 
TransactionAttributeSource.class); 
sourceDef.setSource(eleSource); 
sourceDef.setRole(BeanDefinition.ROLE INFRASTRUCTURE); 
/注册 bean, 并 使 用 Spring 中 的 定义 规则 生成 beaanname 
String sourceName = parserContext.getReaderContext(). 


registerWithGeneratedName 


(sourceDef); 
/创建 TransactionInterceptor 的 bean 
RootBeanDefinition interceptorDef = new RootBeanDefinition 
(TransactionInterceptor.class); 


interceptorDef.setSource(eleSource); 


interceptorDef.setRole(BeanDefinition. ROLE INFRASTRUCTURE); 
registerTransactionManager(element, interceptorDef); 
interceptorDef.getProperty V alues().add("transactionAttributeSource", 
new RuntimeBeanReference(sourceName)); 
/注册 bean, 并 使 用 Spring 中 的 定义 规则 生成 beanname 
String interceptorName = parserContext.getReaderContext(). 
Register 
WithGeneratedName(interceptorDef); 
/创建 TransactionAttributeSourceAdvisor 的 bean 
RootBeanDefinition advisorDef = new RootBeanDefinition 
(BeanFactory 
TransactionAttributeSourceAdvisor.class); 
advisorDef.setSource(eleSource); 
advisorDef.setRole(BeanDefinition.ROLE INFRASTRUCTURE); 
/将 sourceName 的 bean 注 入 advisorDef 的 transactionAttributeSource 
属性 中 
advisorDef.getProperty V alues().add("transactionAttributeSource", 
new RuntimeBeanReference(sourceName)); 
/将 interceptorName 的 bean 注 入 advisorDef 的 adviceBeanName 属 性 


advisorDef.getPropertyValues().add("adviceBeanName", 


interceptorName); 
/如 果 配 置 了 order 属 性 ， 则 加 入 到 bean 中 
if (element.hasAttribute("order")) { 
advisorDef.getProperty Values().add("order", 
element.getAttribute 
("order")); 


parserContext.getRegistry().registerBeanDefinition(tx AdvisorBeanName, 
advisorDef); 
/创建 CompositeComponentDefinition 
CompositeComponentDefinition compositeDef = new 
CompositeComponent 
Definition(element.getTagName(), eleSource); 
compositeDef.addNestedComponent(new 
BeanComponentDefinition (sourceDef, 
sourceName)); 
compositeDef.addNestedComponent(new 
BeanComponentDefinition(interceptorDef, 
interceptorName)); 
compositeDef.addNestedComponent(new 
BeanComponentDefinition(advisorDef, 
txAdvisorBeanName)); 


parserContext.registerComponent(compositeDef); 


} 
上 面 的 代码 注册 了 代理 类 及 三 个 bean， 很 多 读者 会 直接 略 过 ， 认 为 


只 是 注册 三 个 bean 而 已 ， 确 实 ， 这 里 只 注册 了 三 个 bean， 但 是 这 三 个 
bean 文 撑 了 整个 的 事务 功能 ， 那 么 这 三 个 bean 是 怎么 组 织 起 来 的 呢 ? 
首先 ， 其 中 的 两 个 bean 被 注册 到 了 一 个 名 为 advisorDef 的 bean 
中 ，advisorDef 使 用 BeanFactoryTransactionAttributeSourceAdvisor 作为 
其 class 属性 。 也 就 是 说 BeanFactoryTransaction AttributeSourceAdvisor 代 
表 着 当前 bean， 如 图 10-1 所 示 ， 具 体 代码 如 下 : 
advisorDef.getProperty Values().add("adviceBeanName", 


interceptorName); 


BeanFactoryTransactionAttributeSourceAdvisor 
并 


AnnotationTransactionAttributeSource TransactionInterceptor 
E 


图 10-1 BeanFactoryTransactionAttributeSourceAdvisor 的 组 装 











那么 如 此 组 厂 的 目的 是 什么 呢 ? 我 们 知 且 留 下 一 个 悬念 ， 接 着 分 析 
代码 。 上 面 函 数 configureAutoProxyCreator 中 的 第 一 句 貌 似 很 简单 但 却 
是 很 重要 的 代码 : 

AopNamespaceUtils.registerAutoProxyCreatorIf Necessary(parserContex 
element); 

进入 这 个 函数 : 

public static void registerAutoProxyCreatorIfNecessary( 

ParserContext parserContext, Element sourceElement) { 


BeanDefinition beanDefinition = 


AopConfigUtils.registerAutoProxyCreatorlf 
Necessary( 
parserContext.getRegistry(), parserContext.extractSource (source 
Element)); 
useClassProxyingIfNecessary(parserContext.getRegistry(), 
sourceElement); 
registerComponentlIf Necessary(beanDefinition, parserContext); 
j 
public static BeanDefinition 
registerAutoProxyCreatorIf Necessary(BeanDefinitionRegistry 
registry, Object source) 1 
return 
registerOrEscalateApcAsRequired(InfrastructureAdvisorAutoProxyCreator. 
class, registry, source); 
j 
对 于 解析 来 的 代码 流程 AOP 中 已 经 有 所 分 析 ， 上 面 的 两 个 函数 主 
要 目的 是 注册 了 InfrastructureAdvisorAutoProxyCreator 类 型 的 bean， 那 
么 注册 这 个 类 的 目的 是 什么 呢 ? 碍 看 这 个 类 的 层次 ， 如 图 10-2 所 示 。 





I^. ik EY 
| 4 CN InfrastructureAdvisorAutoProxyCreator 
4 (9^ AbstractAdvisorAutoProxyCreator 
4 (9^ AbstractAutoProxyCreator 
4 (9 ProxyConfig 
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Q BeanClassLoaderAware 
@ Aware 
4 © BeanFactoryAware 
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Q Ordered 
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A 


© InstantiationAwareBeanPostProcessor 





Q BeanPostProcessor 





图 10-2 InfrastructureAdvisorAutoProxyCreator 类 的 层次 结构 图 


从 上 面 的 层次 结构 中 可 以 看 到 ， 
InfrastructureAdvisorAutoProxyCreator 间接 实现 了 
SmartInstantiationAwareBeanPostProcessor， 而 
SmartInstantiationA wareBeanPostProcessor X. 4k 7K Ej 
InstantiationA wareBeanPostProcessor, ti it2Ui7ESpring'F, Pre beans 
例 化 时 Spring 都 会 保证 调用 其 postProcessAfterInitialization 方 法 ， 其 实现 
是 在 父 类 AbstractAutoProxyCreator 类 中 实现 。 

以 之 前 的 示例 为 例 ， 当 实例 化 userService 的 bean 时 便 会 调用 此 方 
iE, ARUP: 

public Object postProcessA fterInitialization(Object bean, String 
beanName) throws 

BeansException { 

if (bean != null) { 


/根据 给 定 的 bean 的 class 和 name 构 建 出 个 key， 
beanClassName_beanName 
Object cacheKey = getCacheKey(bean.getClass(), beanName); 
IL R Fe E T 8E H6 8 S OS TT B EE] bean f CT 
if (!this.earlyProxyReferences.contains(cacheKey)) { 


return wrapIfNecessary(bean, beanName, cacheKey); 


} 
return bean; 
} 
这 里 实现 的 主要 目的 是 对 指定 bean 进行 封装 ， 当 然 首先 要 确定 是 
个 需 要 封装 ， 检 测 及 封装 的 工作 都 委托 给 了 wrapIfNecessary 函 数 进行 。 
protected Object wrapIfNecessary(Object bean, String beanName， 
Object cacheKey) { 
/如 果 已 经 处 理 过 
if (this.targetSourcedBeans.contains(beanName)) { 
return bean; 
} 
if (this. nonAdvisedBeans.contains(cacheKey)) { 
return bean; 
} 
/给 定 的 bean 类 是 否 代表 一 个 基础 设施 类 ， 不 应 代理 ,或 者 配置 了 
旨 定 bean 不 需要 自动 代理 
if (isInfrastructureClass(bean.getClass()) || 
shouldSkip(bean.getClass(), 
beanName)) { 
this.nonAdvisedBeans.add(cacheKey); 











return bean; 
} 
// Create proxy if we have advice. 
Object[] specificInterceptors = 
getAdvicesAndAdvisorsForBean(bean.getClass(), 
beanName, null); 
if (specificInterceptors != DO NOT PROXY) { 
this.advisedBeans.add(cacheKey); 
Object proxy = createProxy(bean.getClass(), beanName, 
specificInterceptors, 
new SingletonTargetSource(bean)); 
this.proxyTypes.put(cacheKey, proxy.getClass()); 
return proxy; 
j 
this.nonAdvisedBeans.add(cacheK ey); 
return bean; 
j 
wrapIfNecessary 函数 功能 实现 起 来 很 复杂 ， 但 是 逻辑 上 理解 起 来 还 
是 相对 简单 的 ， 在 wrapIfNecessary 函 数 中 主要 的 工作 如 下 。 
(1) 找 出 指定 bean 对 应 的 增强 器 。 
(20 根据 找 出 的 增强 器 创建 代理 。 
上 听 起 来 似乎 简单 的 逻辑 ，Spring 中 又 做 了 哪些 复杂 的 工作 呢 ? 对 于 
创建 代理 的 部 分 ， 通 过 之 前 的 分 析 相 信 大 家 已 经 很 熟悉 了 ， 但 是 对 于 增 
强 器 的 获取 ，Spring 又 是 怎么 做 的 呢 ? 





获取 指定 bean 对 应 的 增强 器 ， 其 中 包含 两 个 关键 字 : 增强 需 与 对 





应 。 也 就 是 说 在 getAdvicesAndAdvisorsForBean 函数 中 ， 不 但 要 找 出 增 
强 器 ， 而 且 还 需要 判断 增强 堪 是 侣 满足 要 求 。 
protected Object[ ] getAdvicesAndAdvisorsForBean(Class beanClass, 
String beanName, 
TargetSource targetSource) { 
List advisors = findEligibleAdvisors(beanClass, beanName); 
if (advisors.isEmpty()) { 
return DO_NOT_PROXY; 
} 
return advisors.toArray(); 
} 
protected List<Advisor> findEligibleAdvisors(Class beanClass, String 
beanName) { 
List<Advisor> candidateAdvisors = findCandidateA dvisors(); 
List<Advisor> eligibleAdvisors = 
findAdvisorsThatCanA pply(candidateAdvisors, 
beanClass, beanName); 
extendAdvisors(eligibleAdvisors); 
if (leligibleAdvisors.isEmpty()) { 
eligibleAdvisors = sortAdvisors(eligibleAdvisors); 
j 
return eligibleAdvisors; 
j 
其 实 我 们 也 渐渐 地 体会 到 了 Spring 中 代码 的 优秀 ， 即 使 是 一 个 很 复 
RME, E Spring 中 也 会 被 拆 分 成 耕 干 个 小 的 逻辑 ， 然 后 在 每 个 函数 
中 实现 ， 使 得 每 个 函数 的 逻辑 简单 到 我 们 能 快速 地 理解 ， 而 不 会 像 有 些 
人 开发 的 那样 ， 将 一 大 堆 的 逻辑 都 罗列 在 一 个 函数 中 ， 给 后 期 维护 人 员 


造成 巨大 的 困扰 。 
同样 ， 通 过 上 面 的 函数 ，Spring 又 将 任务 进行 了 拆 分 ， 分 成 了 获取 
所 有 增强 器 与 增强 器 是 否 风 配 两 个 功能 点 。 
1. 寻找 候选 增强 器 
在 findCandidateAdvisors 函 数 中 完成 的 就 是 获取 增强 器 的 功能 。 
protected List<Advisor> findCandidateAdvisors() { 











return this.advisorRetrievalHelper.findAdvisorBeans(); 
} 
public List<Advisor> findAdvisorBeans() { 
// Determine list of advisor bean names, if not cached already. 
String[ ] advisorNames = null; 
synchronized (this) { 
advisorNames = this.cachedAdvisorBeanNames; 
if (advisorNames == null) { 
advisorNames = 
BeanFactory Utils.beanNamesForTypelIncluding Ancestors( 
this.beanFactory, Advisor.class, true, false); 


this.cachedAdvisorBeanNames = advisorNames; 


} 
if (advisorNames.length == 0) { 
return new LinkedList<Advisor>(); 
} 
List<Advisor> advisors = new LinkedList<Advisor>(); 
for (String name : advisorNames) { 
if (isEligibleBean(name) && 


Ithis.beanFactory.isCurrentlyInCreation(name)) { 


try { 

advisors.add(this.beanFactory.getBean(name, Advisor.class)); 
} 
catch (BeanCreationException ex) { 

Throwable rootCause = ex.getMostSpecificCause(); 


if (rootCause instanceof BeanCurrentlyInCreationException) 


BeanCreationException bce = (BeanCreationException) 
rootCause; 
if 
(this.beanFactory.isCurrentlyInCreation(bce.getBeanName())) 1 
if (logger.isDebugEnabled()) 1 
logger.debug("Ignoring currently created advisor '" 
+ name + '"': " + ex.getMessage()); 
j 


continue; 


} 


throw ex; 


} 
return advisors; 
} 
WT ERMA, PRAT PY DR» Pg? 首先 是 通过 
BeanFactoryUtils 类 提供 的 工具 方法 获取 所 有 对 应 Advisor.class 的 类 ， 获 
取 办 法 无 非 是 使 用 ListableBeanFactory 中 提供 的 方法 : 





String[] getBeanNamesForType(Class<?> type, boolean 
includeNonSingletons, boolean 

allowEagerlnit); 

而 当 我 们 知道 增强 器 在 容器 中 的 beanName 时 ， 获 取 增 强 器 已 经 不 
是 问题 了 ， 在 BeanFactory 中 提供 了 这 样 的 方法 ， 可 以 帮助 我 们 快速 定位 
对 应 的 bean 实 例 。 

<T> T getBean(String name, Class<T> requiredType) throws 
BeansException; 

或 许 你 已 经 筷 了 之 前 留 下 的 巧 念 ， 在 我 们 讲解 目 定 义 标签 时 曾经 注 
册 了 一 个 类 型 为 BeanFactoryTransactionAttributeSourceAdvisor 的 bean, 
而 在 此 bean 中 我 们 又 注入 了 另外 两 个 Bean， 那 么 此 时 这 个 Bean 融会 被 
开始 使 用 了 。 因 为 BeanFactoryTransactionAttribute Source Advisor 同 样 也 
实现 了 Advisor 接 口 ， 那 么 在 获取 所 有 增强 器 时 上 自然 也 会 将 此 bean 提 取出 
来 ， 并 随 着 其 他 增强 器 一 起 在 后 续 的 步 缀 中 被 织 入 代理 。 

2. 候选 增强 絮 中 寻找 到 匹配 项 

当 找 出 对 应 的 增强 器 后 ， 接 来 的 任务 就 是 看 这 些 增强 器 是 人 否 与 对 应 
的 class 匹配 了 ， 当 然 不 只 是 class，class 内 部 的 方法 如 果 匹 配 也 可 以 通 
过 验证 。 

public static List<Advisor> findAdvisorsThatCanApply(List<Advisor> 








candidateAdvisors, 
Class<?> clazz) { 
if (candidateAdvisors.isEmpty()) { 
return candidateAdvisors; 
} 
List<Advisor> eligibleAdvisors = new LinkedList<Advisor>(); 
/首先 处 理 引 介 增 强 


for (Advisor candidate : candidateAdvisors) { 


if (candidate instanceof IntroductionAdvisor && 
canApply(candidate, clazz)) { 
eligibleAdvisors.add(candidate); 


} 
boolean hasIntroductions = !eligibleAdvisors.isEmpty(); 
for (Advisor candidate : candidateAdvisors) { 
/ 引 介 增强 已 经 处 理 
让 (candidate instanceof IntroductionAdvisor) { 
Continue; 
} 
/对 于 普通 bean 的 处 理 
if (canApply(candidate, clazz, hasIntroductions)) { 
eligibleAdvisors.add(candidate); 


} 
return eligibleAdvisors; 
} 
public static boolean canApply(Advisor advisor, Class<?> targetClass, 
boolean 
hasIntroductions) { 
if (advisor instanceof IntroductionAdvisor) { 
return((IntroductionAdvisor)advisor).getClassFilter().Matches 
(targetClass); 
}else if (advisor instanceof PointcutAdvisor) { 
PointcutAdvisor pca = (PointcutAdvisor) advisor; 


return canApply(pca.getPointcut(), targetClass, hasIntroductions); 


yelse { 


return true; 


j 
当前 我 们 分 析 的 是 对 于 UserService 是 否 适 用 于 此 增强 方法 ， 那 么 当 
前 的 advisor 就 是 之 前 查找 出 来 的 类 型 为 
BeanFactoryTransactionAttributeSourceAdvisor 的 bean 实 例 ， 而 通过 类 的 
层次 结构 我 们 又 知道 : BeanFactoryTransactionAttributeSourceAdvisor 间 
接 实 现 了 PointcutAdvisor。 因 此 ， 在 canApply 函数 中 的 第 二 个 证 判断 
时 就 会 通过 判断 ， 会 将 BeanFactory Transaction AttributeSourceAdvisor 
中 的 getPointcut0) 方 法 返回 值 作为 参数 继续 调用 canApply 方法 ， 而 
getPoint() 方 法 返回 的 是 TransactionAttributeSourcePointcut 类 型 的 实例 。 
对 于 transactionAttribute Source 这 个 属性 大 家 还 有 印象 吗 ? 这 是 在 解析 
自 定义 标签 时 注入 进去 的 。 
private final TransactionAttributeSourcePointcut pointcut = new 
TransactionAttribute 
SourcePointcut() { 
@Override 
protected TransactionAttributeSource 
getTransactionAttributeSource() { 
return transactionAttributeSource; 
} 
H 
那么 ， 使 用 ransactionAttributeSourcePointcut 类 型 的 实例 作为 函数 参 
数 继续 跟踪 canApply。 
public static boolean canApply(Pointcut pc, Class<?> targetClass, 


boolean hasIntroductions) { 


Assert.notNull(pc, "Pointcut must not be null"); 
if (!*pc.getClassFilter().matches(targetClass)) 1 
return false; 


j 
/此 时 的 pc 表示 TransactionAttributeSourcePointcut 


/pc.getMethodMatcher(0 返 回 的 正 是 自身 (this). 
MethodMatcher methodMatcher = pc.getMethodMatcher(); 
IntroductionA wareMethodMatcher 


introductionAwareMethodMatcher = null; 
if (methodMatcher instanceof IntroductionAwareMethodMatcher) { 


introductionA wareMethodMatcher = 
(IntroductionAwareMethodMatcher) methodMatcher; 
} 
Set<Class> classes = new HashSet<Class>(Class Utils. 


GetAllInterfaces 

ForClassAsSet(targetClass)); 
classes.add(targetClass); 
//classes:[interface test.ITTestBean, class test. TestBean] 
for (Class<?> clazz : classes) 1 

Method[] methods = clazz.getMethods(); 

for (Method method : methods) { 

if ((introductionAwareMethodMatcher != null && 


introductionA wareMethodMatcher.matches(method, 


targetClass, 
hasIntroductions)) || 
methodMatcher.matches(method, targetClass)) { 


return true; 


} 
return false; 

} 

通过 上 面 函 数 大 致 可 以 理 清 大 体 脉 络 ， 首 先 获 取 对 应 类 的 所 有 接口 
并 连同 类 本 和 映 一 起 过 历 ， 裔 历 过 程 中 又 对 类 中 的 方法 再 次 这 历 ， 一 旦 匹 
配 成 功 便 认为 这 个 类 适用 于 当前 增强 器 。 

到 这 里 我 们 不 蔡 会 有 疑问 ， 对 于 事物 的 配置 不 仅仅 局 限于 在 函数 上 
配置 ， 我 们 都 知道 ， 在 类 活 接口 上 的 配置 可 以 延续 到 类 中 的 每 个 函数 ， 
那么 ， 如 有 果 针 对 每 个 函数 进行 检测 ， 在 类 本 身上 配置 的 事务 属性 岂 不 是 
检测 不 到 了 吗 ? 和 带 着 这 个 疑问 ， 我 们 继续 探求 matcher 方 法 。 

做 匹配 的 时 候 methodMatcher.matches(method, targetClass) 会 使 用 


TransactionAttributeSource Pointcut 类 的 matches 方 法 。 




















public boolean matches(Method method, Class targetClass) { 
/ 自 定义 标签 解析 时 注入 
TransactionAttributeSource tas = getTransactionAttributeSource(); 
return (tas == null || tas.getTransactionAttribute(method, targetClass) 
!- null); 

} 

此 时 的 tas 表 示 AnnotationTransactionAttributeSource 类 型 ， 而 
AnnotationTransactionAttribute Source 类 型 的 getTransactionAttribute 方 法 
如 下 : 

public TransactionAttribute getTransactionAttribute(Method method, 
Class<?> 

targetClass) { 

Object cacheKey = getCacheKey(method, targetClass); 


Object cached = this.attributeCache.get(cacheKey); 
if (cached != null) { 
if (cached == NULL_TRANSACTION_ATTRIBUTE) { 
return null; 
} 
else { 


return (TransactionAttribute) cached; 


} 
else { 
TransactionAttribute tx Att = 
computeTransactionAttribute(method, targetClass); 
// Put it in the cache. 
if (txAtt == null) { 
this.attributeCache.put(cacheKey, 
NULL TRANSACTION ATTRIBUTE); 
j 
else { 
if (logger.isDebugEnabled()) { 
logger.debug(" Adding transactional method " + 
method.getName() 
+ ™ with attribute: " + txAtt); 
} 
this.attributeCache.put(cacheKey, txAtt); 
} 
return txAtt; 


} 

很 遗憾 ， 在 getTransactionAttribute 函 数 中 并 没有 找到 我 们 想 要 的 代 
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被 缓存 的 话 ， 工 作 又 委托 给 了 computeTransaction Attribute 函 数 ， 在 
compnuteTransactionAttribute 函 数 中 终于 的 我 们 看 到 了 事务 标 俭 的 提取 过 
f£. 

3. 提取 事务 标签 


private TransactionAttribute computeTransactionAttribute(Method 








method, Class<?> 
targetClass) { 

// Don't allow no-public methods as required. 

if (allowPublicMethodsOnly() && 
!Modifier.isPublic(method.getModifiers())) { 

return null; 

} 

// Ignore CGLIB subclasses - introspect the actual user class. 

Class<?> userClass = ClassUtils.getUserClass(targetClass); 

/method 代 表 接 口中 的 方法 ，specificMethod 代 表 实 现 类 中 的 方法 

Method specificMethod = 
ClassUtils.getMostSpecificMethod(method, userClass); 








// If we are dealing with method with generic parameters, find the 
original method. 

specificMethod = 
BridgeMethodResolver.findBridgedMethod(specificMethod); 

/查看 方法 中 是 否 存在 事务 声明 


TransactionAttribute txAtt = 








findTransactionAttribute(specificMethod); 


if (txAtt != null) { 
return txAtt; 





} 
// 伍 看 方法 所 在 类 中 是 否 存在 事务 声明 
txAtt = 


findTransactionAttribute(specificMethod.getDeclaringClass()); 
if (txAtt != null) { 
return txAtt; 
} 
/如 果 存 在 接口 ， 则 到 接口 中 去 寻找 
if (specificMethod != method) { 
// 查 找 接 口 方法 
txAtt = findTransactionAttribute(method); 
if (txAtt != null) { 
return txAtt; 
} 
/到 接口 中 的 类 中 去 寻找 
return findTransactionAttribute(method.getDeclaringClass()); 
} 
return null; 

} 

对 于 事务 属性 的 获取 规则 相信 大 家 都 已 经 很 清楚 ， 如 果 方 法 中 存在 
事务 属性 ， 则 使 用 方法 上 的 属性 ， 人 否则 使 用 方法 所 在 的 类 上 的 属性 ， 如 
果 方 法 所 在 类 的 属性 上 还 是 没有 搜寻 到 对 应 的 事务 属性 ， 那 么 再 搜寻 接 
口中 的 方法 ， 再 没有 的 话 ， 最 后 尝试 搜寻 接口 的 类 上 面 的 声明 。 对 于 函 
数 computeTransactionAttribute 中 的 多 辑 与 我 们 所 认识 的 规则 并 无 差别 ， 
但 是 上 面 函 数 中 并 没有 真正 的 去 做 搜寻 事务 属性 的 逻辑 ， 而 是 搭建 了 个 























执行 框架 ， 将 搜寻 事务 属性 的 任务 委托 给 了 findTransactionAttribute 方 法 
去 执行 。 
protected TransactionAttribute findTransactionAttribute(Method 
method) { 
return determineTransactionA ttribute(method); 
} 


protected TransactionAttribute 





determineTransactionAttribute(AnnotatedElement ae) { 
for (TransactionAnnotationParser annotationParser : 
this.annotationParsers) { 
TransactionAttribute attr = annotationParser.parseTransaction 
Annotation (ae); 
if (attr != null) { 


return attr; 


} 
return null; 
} 
this.annotationParsers 是 在 当前 类 
AnnotationTransactionAttributeSource 初 始 化 的 时 候 初 始 化 的 ， 其 中 的 值 
被 加 入 了 SpringTransactionAnnotationParser， 也 就 是 当 进 行 属 性 获取 的 
时 候 其 实 是 使 用 SpringTransactionAnnotationParser 类 的 
parseTransactionAnnotation 方法 进行 解析 的 。 
public TransactionAttribute 
parseTransactionAnnotation(AnnotatedElement ae) { 
Transactional ann = AnnotationUtils.getAnnotation(ae, 


Transactional.class); 


if (ann != null) { 

return parseTransactionAnnotation(ann); 
} 
else { 


return null; 


} 

至 此 ， 我 们 终于 看 到 了 想 看 到 的 获取 注解 标记 的 代码 。 首 移 会 判断 
当前 的 类 是 人 否 含 有 Transactional 注解 ， 这 是 事务 属性 的 基础 ， 当 然 如 果 
有 的 话 会 继续 调用 parseTransactionAnnotation 方 法 解析 详细 的 属性 。 

public TransactionAttribute parseTransactionAnnotation(Transactional 
ann) { 

RuleBasedTransactionAttribute rbta = new 
RuleBasedTransactionAttribute(); 

/解析 propagation 

rbta.setPropagationBehavior(ann.propagation().value()); 

/解析 isolation 

rbta.setIsolationLevel(ann.isolation().value()); 

/解析 timeonut 

rbta.setTimeout(ann.timeout()); 

/解析 readOnly 

rbta.setReadOnly(ann.readOnly()); 

/解析 value 

rbta.setQualifier(ann.value()); 

ArrayList<RollbackRuleAttribute> rollBackRules = new 
ArrayList«RollbackRule 

Attribute» (); 


/解析 rollbackFor 
Class[] rbf = ann.rollbackFor(); 
for (Class rbRule : rbf) { 
RollbackRuleAttribute rule = new RollbackRuleAttribute(rbRule); 
rollBackRules.add(rule); 
} 
/解析 rollbackForClassName 
String[] rbfc = ann.rollbackForClassName(); 
for (String rbRule : rbfc) { 
RollbackRuleAttribute rule = new RollbackRuleAttribute(rbRule); 
rollBackRules.add(rule); 
j 
/解析 noRollbackFor 
Class[] nrbf = ann.noRollbackFor(); 
for (Class rbRule : nrbf) { 
NoRollbackRuleAttribute rule = new 
NoRollbackRuleAttribute(rbRule); 
rollBackRules.add(rule); 
j 
/解析 noRollbackForClassName 
String[] nrbfc = ann.noRollbackForClassName(); 
for (String rbRule : nrbfc) { 
NoRollbackRuleAttribute rule = new 
NoRollbackRuleAttribute(rbRule); 
rollBackRules.add(rule); 
j 
rbta.getRollbackRules().addAll(rollBackRules); 


return rbta; 

} 

上 面 方法 中 实现 了 对 对 应 类 或 者 方法 的 事务 属性 解析 ， 你 会 在 这 个 
类 中 看 到 任何 你 常用 或 者 不 党 用 的 属性 提取 。 

至 此 ， 我 们 终于 完成 了 事务 标签 的 解析 。 我 们 是 不 是 分 析 的 太 远 
了 ， 似 乎 已 经 筷 了 从 哪里 开始 了 。 再 回顾 一 下 ， 我 们 的 现在 的 任务 是 找 
出 某 个 增强 器 是 否 适 合 于 对 应 的 类 ， 而 是 否 匹配 的 关键 则 在 于 是 人 否 从 指 
定 的 类 或 类 中 的 方法 中 找到 对 应 的 事务 属性 ， 现 在 ， 我 们 以 
UserServiceImp] 为 例 ， 已 经 在 它 的 接口 UserService 中 找到 了 事务 属性 ， 
所 以 ， 它 是 与 事务 增强 器 匹配 的 ， 也 就 是 它 会 被 事务 功能 修饰 。 

至 此 ， 事 务 功能 的 初始 化 工作 便 结束 了 ， 当 判断 某 个 bean 适用 于 
事务 增强 时 ， 也 就 是 适用 于 增强 峰 
BeanFactoryTransactionAttributeSourceAdvisor， 没 错 ， 还 是 这 个 类 ， 所 
以 说 ， 在 和 目 定义 标签 解析 时 ， 注 入 的 类 成 为 了 整个 事务 功能 的 基础 。 

BeanFactoryTransactionAttributeSourceAdvisor 作 为 Advisor 的 实现 
类 ， 自 然 要 遵从 Advisor 的 处 理 方式 ， 当 代理 被 调用 时 会 调用 这 个 类 的 
增强 方法 ， 也 就 是 此 bean 的 Advise， 又 因为 在 解析 事务 定义 标签 时 我 
们 把 TransactionInterceptor 类 型 的 bean 注入 到 了 BeanFactory 
TransactionAttributeSourceAdvisor 中 ， 所 以 ， 在 调用 事务 增强 器 增强 的 
代理 类 时 会 首先 执行 TransactionInterceptor 进 行 增强 ， 同 时 ， 也 就 是 在 
TransactionInterceptor 类 中 的 invoke 方 法 中 完成 了 整个 事务 的 逻辑 。 























10.3 事务 增强 路 


TransactionInterceptor 文 撑 着 整个 事务 功能 的 架构 ， 人 逻辑 还 是 相对 
复杂 的 ， 那 么 现在 我 们 切入 正题 来 分 析 此 拦截 器 是 如 何 实现 事务 特性 
的 。TransactionInterceptor 类 继承 自 MethodInterceptor， 所 以 调用 该 类 是 


从 其 invoke 方 法 开始 的 ， 首 先 预 览 下 这 个 方法 : 
public Object invoke(final MethodInvocation invocation) throws 
Throwable { 
Class<?> targetClass = (invocation.getThis() != null ? 
AopUtils.getTargetClass 
(invocation.getThis()) : null); 
/获取 对 应 事务 属性 


final TransactionAttribute txAttr = 





getTransactionAttributeSource().getTransactionAttribute (invocation. 
getMethod(), targetClass); 
/获取 beanFactory 中 的 transactionManager 
final PlatformTransactionManager tm = 
determineTransactionManager(txAttr); 
/构造 方法 唯一 标识 〈 类 .方法 ， 如 service.UserServiceImpl.save ) 
final String joinpointIdentification = methodIdentification (invocation. 
getMethod(), targetClass); 
/声明 式 事务 处 理 
if (txAttr == null || !(tm instanceof 
CallbackPreferringPlatformTransaction 
Manager)) { 
/创建 TransactionInfo 
TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, 
joinpoint 
Identification); 
Object retVal = null; 
try { 
/执行 被 增强 方法 


retVal = invocation.proceed(); 
} 
catch (Throwable ex) { 

IRIS LTR 

completeTransactionA fterThrowing(txInfo, ex); 

throw ex; 
} 
finally { 

/清除 信息 

cleanupTransactionInfo(txInfo); 
} 
/提交 事务 
commitTransactionA fterReturning(txInfo); 
return retVal; 

} 
else { 

/编程 式 事务 处 理 
try { 

Object result = 

((CallbackPreferringPlatformTransactionManager) tm). 
execute(txAttr, 
new TransactionCallback<Object>() { 
public Object doInTransaction(TransactionStatus status) { 
TransactionInfo txInfo = prepareTransactionInfo(tm, 
txAttr, joinpointIdentification, status); 
try { 
return invocation.proceed(); 


} 
catch (Throwable ex) { 
if (txAttr.rollbackOn(ex)) { 
// A RuntimeException: will lead to a rollback. 
if (ex instanceof RuntimeException) { 
throw (RuntimeException) ex; 
} 
else { 


throw new ThrowableHolderException(ex); 


} 
else { 
// A normal return value: will lead to a commit. 


return new ThrowableHolder(ex); 


} 
finally { 


cleanupTransactionInfo(txInfo); 


} 
y 
// Check result: It might indicate a Throwable to rethrow. 
if (result instanceof ThrowableHolder) 1 
throw ((ThrowableHolder) result).getThrowable(); 
i 
else { 


return result; 


} 
catch (ThrowableHolderException ex) { 


throw ex.getCause(); 


} 

从 上 面 的 函数 中 ， 我 们 答 试 整理 下 事务 处 理 的 脉络 ， 在 Spring 中 文 
持 两 种 事务 处 理 的 方式 ， 分 别 是 声明 式 事务 处 理 与 编程 式 事务 处 理 ， 两 
者 相对 于 开发 人 员 来 讲 差别 很 大 ， 但 是 对 于 Spring 中 的 实现 来 讲 ， 大 同 
小 异 。 在 invoke 中 我 们 也 可 以 看 到 这 两 种 方式 的 实现 。 考 虑 到 对 事务 的 
应 用 比 声明 式 的 事务 处 理 使 用 起 来 方便 ， 也 相对 流行 些 ， 我 们 就 以 此 种 
方式 进行 分 析 。 对 于 声明 式 的 事务 处 理 主 要 有 以 下 几 个 步骤 。 

(1) 获取 事务 的 属性 。 

对 于 事务 处 理 来 说 ， 最 基础 或 者 说 最 首要 的 工作 便 是 获取 事务 属性 
了 ， 这 是 文 撑 整 个 事务 功能 的 基石 ， 如 有 果 没 有 事务 属性 ， 其 他 功能 也 无 
从 谈 起 ， 在 分 析 事 务 准备 阶段 时 我 们 已 经 分 析 了 事务 属性 提取 的 功能 ， 
大 家 应 该 有 所 了 解 。 

(2) 加载 配置 中 配置 的 TransactionManager。 

C3) 不 同 的 事务 处 理 方式 使 用 不 同 的 逻辑 。 

对 于 声明 式 事务 的 处 理 与 编程 式 事务 的 处 理 ， 第 一 点 区 别 在 于 事务 
属性 上 ， 因 为 编程 式 的 事务 处 理 是 不 需要 有 事务 属性 的 ， 第 二 点 区 别 就 


是 在 TransactionManager 上 ，CallbackPreferring 




















PlatformTransactionManager 实现 PlatformTransactionManager #21, 3& 
露出 一 个 方法 用 于 执行 事务 处 理 中 的 回调 。 所 以 ， 这 两 种 方式 都 可 以 用 
作 事 务 处 理 方式 的 判断 。 

(4). 在 目标 方法 执行 前 获取 事务 并 收集 事务 信息 。 





事务 信息 与 事务 属性 并 不 相同 ， 也 就 是 TransactionInfo 与 
TransactionAttribute 并 不 相同 ， TransactionInfo 中 包含 
TransactionAttribute 信 息 ， 但 是 ， 除 了 TransactionAttribute 外 还 有 其 他 事 


务 信息 ， 例 如 PlatformTransactionManager 以 及 TransactionStatus 相 关 信 
自 
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(5) 执行 目标 方法 。 
(60 一 旦 出 现 异 常 ， 答 试 异 常 处 理 。 
并 不 是 所 有 异常 ，Spring 都 会 将 其 回 深 ， 默 认 只 对 RuntimeException 
回 深 。 
(7) 提交 事务 前 的 事务 信息 清除 。 
(8) 提交 事务 。 
上 面 的 步骤 分 析 则 在 让 大 家 对 事务 功能 与 步骤 有 个 大 致 的 了 解 ， 具 
体 的 功能 还 需要 详细 地 分 析 。 
10.3.1 创建 事务 
我 们 先 分 析 事 务 创建 的 过 程 。 


protected TransactionInfo createTransactionIfNecessary( 





PlatformTransactionManager tm, TransactionAttribute txAttr, final 
String 
joinpointIdentification) { 
// If no name specified, apply method identification as transaction 
name. 
/如 果 没 有 名 称 指定 则 使 用 方法 唯一 标识 ， 并 使 用 
DelegatingTransactionA ttributed} tx Attr 
if (txAttr != null && txAttr.getName() == null) 1 
txAttr = new DelegatingTransactionA ttribute(txAttr) 1 
@Override 


public String getName() { 
return joinpointIdentification; 
j 
js 
j 
TransactionStatus status - null; 
if (txAttr != null) { 
if (tm != null) { 
/获取 TransactionStatus 
status = tm.getTransaction(txAttr); 
} 
else { 
if (logger.isDebugEnabled()) { 
logger.debug("Skipping transactional joinpoint [" + joinpoint 
Identification + 


"] because no transaction manager has been configured"); 


} 
/根据 指定 的 属性 与 status; 准 备 一 个 TransactionInfo 
return prepareTransactionInfo(tm, txAttr, joinpointIdentification, 
status); 
} 
fF createTransactionIfNecessar FK Zo £ (8 SIE Lf SE o 
(1) 使 用 DelegatingTransactionAttribute 封 装 传 入 的 
TransactionAttribute 3 {i 。 
对 于 传 入 的 TransactionAttribute 类 型 的 参数 txAttr， 当 前 的 实际 类 型 


是 RuleBasedTransaction Attribute ， 是 由 获取 事务 属性 时 生成 ， 主 要 用 于 
数据 承载 ， 而 这 里 之 所 以 使 用 Delegating TransactionAttribute 进 行 封 
装 ， 当 然 是 提供 了 更 多 的 功能 。 
(2) 获取 事务 。 
事务 处 理 当 然 是 以 事务 为 核心 ， 那 么 获取 事务 就 是 最 重要 的 事情 。 
(3) 构建 事务 信息 。 
根据 之 前 几 个 步骤 获取 的 信息 构建 TransactionInfo 并 返回 。 
我 们 分 别 对 以 上 步骤 进行 详细 的 解析 。 
1. 获取 事务 
Spring 中 使 用 getTransaction 来 处 理事 务 的 准备 工作 ， 包 括 事务 获取 
以 及 信息 的 构建 。 


public final TransactionStatus getTransaction(TransactionDefinition 














definition) throws 
TransactionException { 
Object transaction = doGetTransaction(); 
// Cache debug flag to avoid repeated checks. 
boolean debugEnabled = logger.isDebugEnabled(); 
if (definition == null) { 
// Use defaults if no transaction definition given. 
definition = new DefaultTransactionDefinition(); 
j 
1/ 判断 当 前 线程 是 否 存 在 事务 ， 判 读 依 据 为 当前 线程 记录 的 连接 不 
为 空 月 连接 中 (connectionHoldem 中 的 
transactionActive 属 性 不 为 空 
if (isExistingTransaction(transaction)) { 
/当前 线程 已 经 存在 事务 


return handleExistingTransaction(definition, transaction, 











debugEnabled); 
} 
/事务 超时 设置 验证 
if (definition.getTimeout() < 
TransactionDefinition. TMEOUT_DEFAULT) { 
throw new InvalidTimeoutException("Invalid transaction timeout", 
definition.getTimeout()); 
} 
/如 果 当 前 线程 不 存在 事务 ， 但 是 propagationBehavior 却 被 声明 为 
PROPAGATION_MANDATORY 抛 
DR 
if (definition.getPropagationBehavior() == TransactionDefinition. 
PROPAGATION . 
MANDATORY) { 
throw new IllegalTransactionStateException( 
"No existing transaction found for transaction marked with 
propagation 'mandatory""); 
Jelse if (definition.getPropagationBehavior() == 
TransactionDefinition. 
PROPAGATION REQUIRED || 
definition.getPropagationBehavior() == TransactionDefinition. 
PROPAGATION 
REQUIRES NEW || 
definition.getPropagationBehavior() == 
TransactionDefinition.PROPAGATION NESTED) { 
//(PROPAGATION REQUIRED, 
PROPAGATION REQUIRES NEW. PROPAGATION NESTED/I[ rij 2 


新 建 事务 
// 空 挂 起 
SuspendedResourcesHolder suspendedResources = suspend(null); 
if (debugEnabled) { 
logger.debug("Creating new transaction with name [" + 
definition. 
getName() + "|: " + definition); 
j 
try 1 
boolean newSynchronization = 
(getTransactionSynchronization() != 
SYNCHRONIZATION NEVER); 
DefaultTransactionStatus status = newTransactionStatus( 
definition, transaction, true, newSynchronization, 
debugEnabled, 
suspendedResources); 
f* 
* 构造 transaction ,包括 设置 ConnectionHolder、 隔 离 级 别 、 
timout 
* 如 果 是 新 连接 ， 绑 定 到 当前 线程 
a 
doBegin(transaction, definition); 
/新 则 步 事 务 的 设置 ， 针 对 于 当前 线程 的 设置 
prepareSynchronization(status, definition); 
return status; 
} 


catch (RuntimeException ex) 1 


resume(null, suspendedResources); 
throw ex; 

} 

catch (Error err) { 
resume(null, suspendedResources); 


throw err; 


} 

else { 
// Create "empty" transaction: no actual transaction, but potentially 
synchronization. 


boolean newSynchronization = (getTransactionSynchronization() 


SYNCHRONIZATION_ALWAYS); 
return prepareTransactionStatus(definition, null, true, 
newSynchronization, 
debugEnabled, null); 
} 
} 
当然 ， 在 Spring 中 每 个 复杂 的 功能 实现 ， 并 不 是 一 次 完成 的 ， 而 是 
会 通过 入 口 函 数 进行 一 个 框架 的 搭建 ， 初 步 构建 完整 的 逻辑 ， 而 将 实现 
MES 数 。 那 么 ， 让 我 们 看 看 事务 的 准备 工作 都 包括 哪 


IE 


(1) 获取 事务 
创建 对 应 的 事务 实例 ， 这 里 使 用 的 是 DataSourceTransactionManager 
中 的 doGetTransaction 方 法 ， 创 建 基于 JDBC 的 事务 实例 。 如 果 当 前 线程 
中 存在 关于 dataSource 的 连接 ， 那 么 直接 使 用 。 这 里 有 一 个 对 保存 点 的 








设置 ， 是 否 开 启 允 许 保存 点 取决 于 是 否 设 置 了 允许 散 入 式 事务 。 
protected Object doGetTransaction() { 
DataSourceTransactionObject txObject = new 
DataSourceTransactionObject(); 
txObject.setSavepointAllowed(isNestedTransactionAllowed()); 
/如 果 当 前 线程 已 经 记录 数据 库 连 接 则 使 用 原 有 连接 


ConnectionHolder conHolder = 





(ConnectionHolder) 
TransactionS ynchronizationManager.getResource(this.dataSource); 
/false 表 示 非 新 创建 连接 。 
txObject.setConnectionHolder(conHolder, false); 


return txObject; 


(2) 如 果 当 先 线 程 存 在 事务 ， 则 转 同 舱 套 事 务 的 处 理 。 
(3) 事务 超时 设置 验证 。 
(4) 事务 propagationBehavior 属 性 的 设置 验证 。 
(5) 构建 DefaultTransactionStatus 。 
(6) 完善 transaction， 包 括 设置 ConnectionHolder、 隔 离 级 别 、 
timeout, MRE, MBE BI) WATE. 
对 于 一 些 隔离 级 别 、timeout 等 功能 的 设置 并 不 是 由 Spring 来 完成 
的 ， 而 是 委托 给 底层 的 数据 库 连 接 去 做 的 ， 而 对 于 数据 库 连 接 的 设置 就 
是 在 doBegin 函 数 中 处 理 的 。 
pe 
* 构造 transaction, 包 括 设 置 ConnectionHolder、 隔 离 级 别 、timeout 
* 如 果 是 新 连接 ， 绑 定 到 当前 线程 
a 
@Override 


protected void doBegin(Object transaction, TransactionDefinition 
definition) { 
DataSourceTransactionObject txObject = 
(DataSourceTransactionObject) transaction; 
Connection con = null; 
try { 
if (txObject.getConnectionHolder() == null || 


txObject.getConnectionHolder().isSynchronizedWithTransaction()) { 
Connection newCon = this.dataSource.getConnection(); 
if (logger.isDebugEnabled()) { 
logger.debug(" Acquired Connection [" + newCon + "] for JDBC 
transaction"); 
} 
txObject.setConnectionHolder(new ConnectionHolder(newCon), 


true); 


txObject.getConnectionHolder().setSynchronizedWithTransaction(true); 
con = txObject.getConnectionHolder().getConnection(); 
/设置 隔离 级 别 
Integer previousIsolationLevel = 
DataSourceUtils.prepareConnection 
ForTransaction(con, definition); 
txObject.setPreviousIsolationLevel(previousIsolationLevel); 
/更 改 自动 提 区 设置 ， 由 Spring 控制 提交 
if (con.getAutoCommit()) { 


txObject.setMustRestoreAutoCommit(true); 
if (logger.isDebugEnabled()) { 


logger.debug(" Switching JDBC Connection [" + con + "] to 
manual commit"); 


} 

con.setAutoCommit(false); 
} 
/设置 判断 当前 线程 是 否 存在 事务 的 依据 
txObject.getConnectionHolder().setTransactionActive(true); 
int timeout = determineTimeout(definition); 
if (timeout != TransactionDefinition. TIMEOUT_DEFAULT) { 


txObject.getConnectionHolder().setTimeoutInSeconds(timeout); 


} 

// Bind the session holder to the thread. 

if (txXObject.isNewConnectionHolder()) { 
/将 当前 获取 到 的 连接 绑 定 到 当前 线程 


TransactionS ynchronizationManager.bindResource(getDataSource(), 


txObject.getConnectionHolder()); 


j 
catch (Exception ex) 1 
DataSourceUtils.releaseConnection(con, this.dataSource); 


throw new CannotCreateTransactionException(" Could not open 
JDBC Connection 


for transaction", ex); 


} 

可 以 说 事务 是 从 这 个 函数 开始 的 ， 因 为 在 这 个 函数 中 已 经 开始 尝试 
了 对 数据 库 连 接 的 获取 ， 当 然 ， 在 获取 数据 库 连接 的 同时 ， 一 些 必要 的 
设置 也 是 需要 同步 设置 的 。 

n ZA BOE. 

当然 并 不 是 每 次 都 会 获取 新 的 连接 ， 如 果 当 前 线程 中 的 
connectionHolder 已 经 存在 ， 则 没有 必要 再 次 获取 ， 或 者 ， 对 于 事务 同步 
表示 设置 为 true 的 需要 重新 获取 连接 。 

o 设置 隔离 级 别 以 及 只 读 标 识 。 

你 是 否 有 过 这 样 的 错觉 ? 事务 中 的 只 读 配 置 是 Spring 中 做 了 一 些 处 
HEE? Spring 中 确实 是 针对 只 读 操 作 做 了 一 些 处 理 ， 但 是 核心 的 实现 是 
设置 connection 上 的 readOnly 必 性。 同样 ， 对 于 隔离 级 别 的 控制 也 是 交 由 
connection 去 控制 的 。 

p 更 改 默认 的 提交 设置 。 

如 果 事 务 属 性 是 自动 提交 ， 那 么 需要 改变 这 种 设置 ， 而 将 提交 操作 
委托 给 Spring 来 处 理 。 

q 设置 标志 位 ， 标 识 当前 连接 已 经 被 事务 激活 。 

r 设置 过 期 时 间 。 

s 将 connectionHolder 绑 定 到 当前 线程 。 

设置 隔离 级 别 的 prepareConnectionForTransaction 函 数 用 于 负责 对 底 
层 数 据 库 连 接 的 设置 ， 当 然 ， 只 是 包含 只 读 标识 和 隔离 级 别 的 设置 。 由 
于 强大 的 日 志 及 异常 处 理 ， 显 得 函数 代码 量 比较 大 ， 但 是 单 从 业务 角度 
去 看 ， 关 键 代 码 其 实 是 不 多 的 。 


public static Integer prepareConnectionForTransaction(Connection con, 

















Transaction Definition 
definition) 


throws SQLException { 


Assert.notNull(con, "No Connection specified"); 
/设置 数据 连接 的 只 读 标识 
if (definition != null && definition.isReadOnly()) { 
try { 
if (logger.isDebugEnabled()) { 
logger.debug(" Setting JDBC Connection [" + con + "] read- 
only"); 
} 
con.setReadOnly(true); 
} 
catch (SQLException ex) { 
Throwable exToCheck = ex; 
while (exToCheck != null) { 
if 
(exToCheck.getClass().getSimpleName().contains(""Timeout")) { 
// Assume it's a connection timeout that would otherwise get 
lost: e.g. from JDBC 4.0 


throw ex; 
} 
ex ToCheck = exToCheck.getCause(); 
} 
logger.debug("Could not set JDBC Connection read-only", ex); 


} 
catch (RuntimeException ex) { 
Throwable exToCheck = ex; 
while (exToCheck != null) { 
if 


(exToCheck.getClass().getSimpleName().contains(""Timeout")) { 
throw ex; 
} 
ex ToCheck = exToCheck.getCause(); 


} 
logger.debug("Could not set JDBC Connection read-only", ex); 


} 
/设置 数据 库 连 接 的 隔离 级 别 
Integer previousIsolationLevel = null; 
if (definition != null && definition.getIsolationLevel() != Transaction 
Definition. ISOLATION_DEFAULT) { 
if (logger.isDebugEnabled()) { 
logger.debug(" Changing isolation level of JDBC Connection [" + 
con + "]to "+ 

definition.getIsolationLevel()); 

j 

int currentIsolation = con.getTransactionIsolation(); 

if (currentIsolation != definition.getIsolationLevel()) 1 

previousIsolationLevel = currentIsolation; 


con.setTransactionlIsolation(definition.getIsolationLevel()); 


} 


return previousIsolationLevel; 
} 
(7) 将 事务 信息 记录 在 当前 线程 中 。 


protected void prepareSynchronization(DefaultTransactionStatus status, 








Transaction 
Definition definition) { 


if (status.isNewSynchronization()) { 


TransactionS ynchronizationManager.setActualTransactionActive(status. 


hasTransaction()); 


TransactionS ynchronizationManager.setCurrentTransactionIsolationLevel( 
(definition.getIsolationLevel() != 

TransactionDefinition. ISOLATION _ 
DEFAULT) ? 


definition.getIsolationLevel() : null); 


TransactionSynchronizationManager.setCurrentTransactionReadOnly 
(definition. 
isReadOnly()); 


TransactionS ynchronizationManager.setCurrentTransactionName(definition. 
getName()); 


TransactionS ynchronizationManager.initS ynchronization(); 


} 

2 处理 已 经 存在 的 事务 

之 前 讲述 了 普通 事务 建立 的 过 程 ， 但 是 Spring 中 支持 多 种 事务 的 传 
播 规 则 ， 比 如 PROPAGATION_NESTED、 
PROPAGATION_REQUIRES_NEW 等 ， 这 些 都 是 在 已 经 存在 事务 的 基 
础 上 进行 进一步 的 处 理 ， 那 么 ， 对 于 已 经 存在 的 事务 ， 准 备 操作 是 如 何 








进行 的 呢 ? 
private TransactionStatus handleExistingTransaction( 
TransactionDefinition definition, Object transaction, boolean 
debugEnabled) 
throws TransactionException { 
if (definition.getPropagationBehavior() == 
TransactionDefinition.PROPAGATION NEVER) { 
throw new Illegal TransactionStateException( 
"Existing transaction found for transaction marked with 
propagation 
never"); 
j 
if (definition.getPropagationBehavior() == 
TransactionDefinition.PROPAGATION NOT . 
SUPPORTED) { 
if (debugEnabled) { 
logger.debug(" Suspending current transaction"); 
j 
Object suspendedResources - suspend(transaction); 
boolean newSynchronization = (getTransactionSynchronization() 
-- SYNCHRONIZATION 
ALWAYS); 
return prepare TransactionStatus( 
definition, null, false, newSynchronization, debugEnabled, 
suspendedResources); 
j 


if (definition.getPropagationBehavior() == 


TransactionDefinition. PROPAGATION _ 
REQUIRES_NEW) { 
if (debugEnabled) { 
logger.debug(""Suspending current transaction, creating new 
transaction 
with name [" + 
definition.getName() + "]"); 
} 
/新 事务 的 建立 
SuspendedResourcesHolder suspendedResources = 
suspend(transaction); 
try { 


boolean newSynchronization = (getTransactionSynchronization() 


SYNCHRONIZATION NEVER); 
DefaultTransactionStatus status = newTransactionStatus( 
definition, transaction, true, newSynchronization, debugEnabled, 
suspendedResources); 
doBegin(transaction, definition); 
prepareSynchronization(status, definition); 
return status; 

j 

catch (RuntimeException beginEx) 1 
resumeAfterBeginException(transaction, suspendedResources, 

beginEx); 


throw beginEx; 


catch (Error beginErr) { 
resumeA fterBeginException(transaction, suspendedResources, 
beginErr); 


throw beginErr; 


} 
RATES AY RR 
if (definition.getPropagationBehavior() == 
TransactionDefinition. PROPAGATION _ 
NESTED) { 
if (!isNestedTransactionAllowed()) { 
throw new NestedTransactionNotSupportedException( 
"Transaction manager does not allow nested transactions by 
default - "+ 
"specify 'nestedTransactionAllowed' property with value 'true"'); 
} 
if (debugEnabled) { 
logger.debug(" Creating nested transaction with name [" + 
definition.getName() + "]"); 
j 
if (useSavepointForNestedTransaction()) 1 
1/ 如果 没 有 可 以 使 用 保存 点 的 方式 控制 事务 回 深 ， 那 么 在 租 入 
式 事务 的 建立 初始 建立 保存 点 


DefaultTransactionStatus status = 





prepareTransactionStatus(definition, transaction, false, 
false, debugEnabled, null); 
status.createAndHoldSavepoint(); 


return status; 
}else { 


// 有 些 情况 是 不 能 使 用 保存 点 操作 ， 比 如 JTA， 那 么 建立 新 事 
物 


boolean newSynchronization = (getTransactionSynchronization() 


SYNCHRONIZATION NEVER); 
DefaultTransactionStatus status = newTransactionStatus( 
definition,transaction, true, newSynchronization, 
debugEnabled, null); 

doBegin(transaction, definition); 
prepareSynchronization(status, definition); 


return status; 


j 
if (debugEnabled) 1 
logger.debug(" Participating in existing transaction"); 
j 
if (isValidateExistingTransaction()) 1 
if (definition.getIsolationLevel() != 
TransactionDefinition.PROPAGATION . 
REQUIRES NEW) { 
Integer currentIsolationLevel = 
TransactionSynchronizationManager. 
getCurrentTransactionIsolationLevel(); 
if (currentIsolationLevel —- null || currentIsolationLevel != 


definition.getIsolationLevel()) { 


Constants isoConstants = 
DefaultTransactionDefinition.constants; 
throw new IllegalTransactionStateException("Participating 
transaction 
with definition [" + 
definition + "] specifies isolation level which is 
incompatible with existing transaction: " + 
(currentIsolationLevel != null ? 
isoConstants.toCode(currentIsolationLevel, 
DefaultTransactionDefinition.PREFIX ISOLATION) : 


"(unknown)")); 


} 
if (!definition.isReadOnly()) { 
if 


(TransactionSynchronizationManager.isCurrentTransactionReadOnly()) 1 
throw new Illegal TransactionStateException(" Participating 
transaction 
with definition [" + 
definition + "] is not marked as read-only but existing 


transaction is"); 


j 

j 

boolean newSynchronization = (getTransactionSynchronization() != 
SYNCHRONIZATION . 


NEVER); 

return prepareTransactionStatus(definition, transaction, false, 
newSynchronization, 

debugEnabled, null); 

} 

对 于 已 经 存在 事务 的 处 理 过 程 中 ， 我 们 看 到 了 很 多 熟悉 的 操作 ， 但 
是 ， 也 有 些 不 同 的 地 方 ， 函 数 中 对 已 经 存在 的 事务 处 理 考虑 两 种 情况 。 

(1) PROPAGATION_REQUIRES_NEW 表示 当前 方法 必须 在 它 自 
己 的 事务 里 运行 ， 一 个 新 的 事务 将 被 局 动 ， 而 如 果 有 一 个 事务 正在 运行 
的 话 ， 则 在 这 个 方法 运行 期 间 被 挂 起 。 而 Spring 中 对 于 此 种 传播 方式 的 
处 理 与 新 事务 建立 最 大 的 不 同 点 在 于 使 用 suspend 方 法 将 原 事务 挂 起 。 
将 信息 挂 起 的 目的 当然 是 为 了 在 当前 事务 执行 完毕 后 在 将 原 事务 还 原 。 

(2) PROPAGATION_NESTED 表示 如 果 当 前 正 有 一 个 事务 在 运行 
F, WZ TIE DAIS TE PRESS H, BURBS BY Whe 
EY AS RS HIERAR, WRN RES NTE, IT AR 
PROPAGATION REQUIRES NEW. X Fie ASRS AREE, Spring 中 
主要 考虑 了 两 种 方式 的 处 理 。 

Spring 中 允许 嵌入 事务 的 时 候 ， 则 首选 设置 保存 点 的 方式 作为 异 第 
处 理 的 回 滚 。 

对 于 其 他 方式 ， 比 如 ITA 无 法 使 用 保存 点 的 方式 ， 那 么 处 理 方式 
5 PROPAGATION REQUIRES NEW 相同 ， 而 一 旦 出 现 异 常 ， 则 由 
Spring 的 事务 异常 处 理 机 制 去 完成 后 续 操作 。 

对 于 挂 起 操作 的 主要 目的 是 记录 原 有 事务 的 状态 ， 以 便于 后 续 操 作 
对 事务 的 恢复 : 


protected final SuspendedResourcesHolder suspend(Object transaction) 



































throws Transaction 


Exception { 


if (TransactionS ynchronizationManager.isSynchronizationActive()) { 
List<TransactionSynchronization> suspendedSynchronizations = 
doSuspend 
Synchronization(); 
try { 
Object suspendedResources = null; 
if (transaction != null) { 
suspendedResources = doSuspend(transaction); 
} 
String name = TransactionSynchronizationManager. GetCurrent 
Transaction 
Name(); 


TransactionS ynchronizationManager.setCurrentTransactionName(null); 
boolean readOnly = 

TransactionS ynchronizationManager.isCurrentTransaction 
ReadOnly(); 


TransactionS ynchronizationManager.setCurrentTransactionReadOnly(false); 
Integer isolationLevel = 
TransactionS ynchronizationManager.getCurrent 


TransactionIsolationLevel(); 


TransactionSynchronizationManager.setCurrentTransactionIsolation 
Level(null); 
boolean wasActive = 


TransactionSynchronizationManager.isA ctual 


TransactionActive(); 


TransactionS ynchronizationManager.setActualTransactionActive(false); 
return new SuspendedResourcesHolder( 
suspendedResources, suspendedSynchronizations, name, 

readOnly, 
isolationLevel, wasActive); 

} 

catch (RuntimeException ex) { 
// doSuspend failed - original transaction is still active... 
doResumeSynchronization(suspendedS ynchronizations); 
throw ex; 

} 

catch (Error err) { 
doResumeSynchronization(suspendedS ynchronizations); 


throw err; 


} 
else if (transaction != null) { 
Object suspendedResources = doSuspend(transaction); 
return new SuspendedResourcesHolder(suspendedResources); 
} 
else { 


return null; 


} 
3. 准备 事务 信息 





当 已 经 建立 事务 连接 并 完成 了 事务 信息 的 提取 后 ， 要 将 所 有 
的 事务 信息 统一 记录 在 TransactionInfo 类 型 的 实例 中 ， 这 个 实例 包含 了 
目标 方法 开始 前 的 所 有 状态 信息 ， 一 旦 事务 执行 失败 ，Spring 会 通过 
TransactionInfo 类 型 的 实例 中 的 信息 来 进行 回 滚 等 后 续 工 作 。 


protected TransactionInfo 











prepare TransactionInfo(PlatformTransactionManager tm, 
TransactionAttribute txAttr, String joinpointIdentification, Transaction 
Status status) { 
TransactionInfo txInfo = new TransactionInfo(tm, txAttr, 
joinpointIdentification); 
if (txAttr != null) { 
// We need a transaction for this method 
if (logger.isTraceEnabled()) 1 
logger.trace(" Getting transaction for [" * txInfo.getJoinpoint 
Identification() * "]"); 
j 
/记录 事务 状态 
txInfo.newTransactionStatus(status); 
} 
else { 
if (logger.isTraceEnabled()) 
logger.trace("Don't need to create transaction for [" + joinpoint 
Identification + 
"|: This method isn't transactional."); 
j 
txInfo.bindToThread(); 


return txInfo; 





之 前 已 经 完成 了 目标 方法 运行 前 的 事务 准备 工作 ， 而 这 些 准备 工作 
最 大 的 目的 无 非 是 对 于 程序 没有 按照 我 们 期 竺 的 那样 进行 ， 也 就 是 出 现 
特定 的 错误 ， 那 么 ， 当 出 现 错 误 的 时 候 ，Spring 是 怎么 对 数据 进行 恢复 
的 呢 ? 


protected void completeTransactionAfterThrowing(TransactionInfo 








txInfo, Throwable ex) { 
// 当 抛 出 异常 时 首先 判断 当前 是 否 存 在 事务 ， 这 是 基础 依据 
if (txInfo != null && txInfo.hasTransaction()) { 
if (logger.isTraceEnabled()) { 


Identification() + 





logger.trace("Completing transaction for [" + txInfo.getJoinpoint 
"] after exception: " * ex); 
j 
/这 里 判断 是 人 否 回 滚 默 认 的 依据 是 抛 出 的 异常 是 个 是 
RuntimeException 或 者 是 Error 的 类 型 
if (txInfo.transactionAttribute.rollbackOn(ex)) { 
try { 
/根据 TransactionStatus 信 息 进 行 回 滚 处 理 


txInfo.getTransactionManager().rollback(txInfo.GetTransaction 
Status()); 
} 
catch (TransactionSystemException ex2) { 


logger.error(" Application exception overridden by rollback 


exception", ex); 
ex2 initApplicationException(ex); 
throw ex2; 
} 
catch (RuntimeException ex2) { 
logger.error(" Application exception overridden by rollback 
exception", ex); 
throw ex2; 
} 
catch (Error err) { 
logger.error(" Application exception overridden by rollback 


error", ex); 





throw err; 
} 
jelse { 
// 如 果 不 满足 回 深 条 件 即 使 抛 出 异常 也 同样 会 提交 
try { 


txInfo.getTransactionManager().commit(txInfo.getTransactionStatus()); 

} 

catch (TransactionSystemException ex2) { 
logger.error(" Application exception overridden by commit 
exception", ex); 
ex2 initApplicationException(ex); 
throw ex2; 

j 


catch (RuntimeException ex2) { 


logger.error(" Application exception overridden by commit 
exception", ex); 
throw ex2; 
} 
catch (Error err) { 
logger.error(" Application exception overridden by commit 
error", ex); 


throw err; 


} 

在 对 目标 方法 的 执行 过 程 中 ， 一 旦 出 现 Throwable 就 会 被 引导 至 此 
方法 处 理 ， 但 是 并 不 代表 所 有 的 Throwable 都 会 被 回 深 处 理 ， 比 如 我 们 
最 常用 的 Exception， 默 认 是 不 会 被 处 理 的 。 默 认 情 况 下 ， 即 使 出 现 异 
第 ， 数 据 也 会 被 正常 提交 ， 而 这 个 关键 的 地 方丈 是 在 txInfo.transaction 
Attribute.rollbackOn(ex)ix ^ K 2X0 

1. [HEIKE 

public boolean rollbackOn(Throwable ex) 1 

return (ex instanceof RuntimeException || ex instanceof Error); 

} 

看 到 了 吗 ? 默 认 情况 下 Spring 中 的 事务 异常 处 理 机 制 只 对 
RuntimeException 和 Error 两 种 情况 感 兴趣 ， 当 然 你 可 以 通过 扩展 来 改 
变 ， 不 过 ， 我 们 最 常用 的 还 是 使 用 事务 提供 的 属性 设置 ， 利 用 注解 方式 
的 使 用 ， 例 如 : 

@Transactional(propagation=Propagation.REQUIRED,rollbackFor=Exc 

2. ENRILE 





当然 ， 一 旦 符合 回 滚 条 件 ， 那 么 Spring 就 会 将 程序 引导 至 回 滚 处 理 
PRA 
public final void rollback(TransactionStatus status) throws 
TransactionException { 
RES CESSARE. WA AKERS e 
if (status.isCompleted()) { 
throw new IllegalTransactionStateException( 
"Transaction is already completed - do not call commit or rollback 
more than once per transaction"); 
} 
DefaultTransactionStatus defStatus = (DefaultTransactionStatus) 
status; 
processRollback(defStatus); 
} 
private void processRollback(DefaultTransactionStatus status) { 
try { 
try { 
/激活 所 有 TransactionSynchronization 中 对 应 的 方法 
triggerBeforeCompletion(status); 
if (status.hasSavepoint()) { 
if (status.isDebug()) { 
logger.debug("Rolling back transaction to savepoint"); 
} 
/如 果 有 保存 点 ， 也 就 是 当前 事务 为 单独 的 线程 则 会 退 到 
保存 点 


status.rollbackToHeldSavepoint(); 


else if (status.isNewTransaction()) { 
if (status.isDebug()) { 


logger.debug("Initiating transaction rollback"); 


} 
// 如 果 当 前 事务 为 独立 的 新 事物 ， 则 直接 回 退 
doRollback(status ); 


} 
else if (status.hasTransaction()) { 
if (status.isLocalRollbackOnly(Q) || 
isGlobalRollbackOnParticipation 
Failure()) 1 
if (status.isDebug()) 1 
logger.debug(" Participating transaction failed - 
marking existing transaction as rollback-only"); 
} 
// 如 果 当 前 事务 不 是 独立 的 事务 ， 那 么 只 能 标记 状态 ， 等 
到 事务 链 执 行 完毕 后 统 
一 回 滚 
doSetRollbackOnly(status); 
} 
else { 
if (status.isDebug()) { 
logger.debug("Participating transaction failed - 


letting transaction originator decide on rollback"); 


else { 
logger.debug(" Should roll back transaction but cannot - no 


transaction available"); 


j 
catch (RuntimeException ex) { 
triggerAfterCompletion(status, 
TransactionSynchronization.STATUS UNKNOWN); 
throw ex; 
j 
catch (Error err) { 
triggerAfterCompletion(status, 
TransactionSynchronization.STATUS UNKNOWN); 
throw err; 
j 
// 激 活 所 有 TransactionSynchronization 中 对 应 的 方法 
triggerAfterCompletion(status, 
TransactionSynchronization.STATUS ROLLED BACK); 
j 
finally { 
/清空 记录 的 资源 并 将 挂 起 的 资源 恢复 
cleanupAfterCompletion(status); 
} 
} 
同样 ， 对 于 在 Spring 中 的 复杂 的 逻辑 处 理 过 程 ， 在 入 口 函数 一 般 都 
会 给 出 个 整体 的 处 理 脉 络 ， 而 把 实现 细节 委托 给 其 他 函数 去 执行 。 我 们 
尝试 总 结 下 Spring 中 对 于 回 滚 处 理 的 大 致 脉络 如 下 。 


(1) 首先 是 自 定义 触发 器 的 调用 ， 包 括 在 回 深 前 、 完 成 回 深 后 的 
调用 ， 当 然 完成 回 滚 包括 正常 回 滚 与 回 滚 过 程 中 出 现 异 常 ， 自 定义 的 触 
2 忌 作 进一步 处 理 ， 而 对 于 触发 器 的 注册 ， 常 见 是 在 回 
调 过 程 中 通过 TransactionSynchronizationManager 类 中 的 静态 方法 直接 注 
Wh: 


public static void registerSynchronization(TransactionS ynchronization 





synchronization) 
(20 除了 触发 监听 函数 外 ， 就 是 真正 的 回 滚 逻 辑 处 理 了 。 

当 之 前 已 经 保存 的 事务 信息 中 有 保存 点 信息 的 时 候 ， 使 用 保存 点 信 
TITER. FATA ASSES, OTH ASU SSS A A, PA RS 
务 异常 并 不 会 引起 外 部 事务 的 回 深 。 

根据 保存 点 回 深 的 实现 方式 其 实 是 根据 底层 的 数据 库 连 接 进行 的 。 

public void rollbackToHeldSavepoint() throws TransactionException { 


if (IhasSavepoint()) { 




















throw new TransactionUsageException(" No savepoint associated 
with current 
transaction"); 
j 
getSavepointManager().rollback ToSavepoint(getSavepoint()); 
setSavepoint(null); 
j 
这 里 使 用 的 是 JDBC 的 方式 进行 数据 库 连 接 ， 那 么 
getSavepointManager0O 函 数 返 回 的 是 JdbcTransactionObjectSupport , tH xè 
是 说 上 面 函数 会 调用 JdbcTransactionObjectSupport 中 的 
rollbackToSavepoint 方 法 。 
public void rollbackToSavepoint(Object savepoint) throws 


TransactionException { 


try { 


getConnectionHolderForSavepoint().getConnection().rollback((Savepoint) 
savepoint); 
j 
catch (Throwable ex) 1 
throw new TransactionSystemException("Could not roll back to 
JDBC savepoint", ex); 
} 
} 
当 之 前 已 经 保存 的 事务 信息 中 的 事务 为 新 事物 ， 那 么 直接 回 深 。 常 
用 于 单独 事务 的 处 理 。 对 于 没有 保存 点 的 回 深 ，Spring 同 样 是 使 用 底层 
数据 库 连 接 提供 的 API 来 操作 的 。 由 于 我 们 使 用 的 是 
DataSourceTransactionManager， 那 么 doRollback 函 数 会 使 用 此 类 中 的 实 
现 : 








protected void doRollback(DefaultTransactionStatus status) { 
DataSourceTransactionObject txObject = 
(DataSourceTransactionObject) 
status.getTransaction(); 
Connection con = txObject.getConnectionHolder().getConnection(); 
if (status.isDebug()) { 
logger.debug(" Rolling back JDBC transaction on Connection [" + 
con + "T; 
} 
try { 
con.rollback(); 


catch (SQLException ex) { 
throw new TransactionSystemException("Could not roll back 
JDBC transaction", ex); 
} 
} 
当前 事务 信息 中 表明 是 存在 事务 的 ， 又 不 属于 以 上 两 种 情况 ， 多 数 
用 于 JTA， 只 做 回 滚 标识 ， 等 到 提交 的 时 候 统 一 不 提交 。 
3， 回 滚 后 的 信息 清除 
对 于 回 深 逻 辑 执 行 结束 后 ， 无 论 回 深 是 否 成 功 ， 都 必须 要 做 的 事情 
就 是 事务 结束 后 的 收尾 工作 。 
private void cleanupA fterCompletion(DefaultTransactionStatus status) { 
/设置 完成 状态 
status.setCompleted(); 

















if (status.isNewSynchronization()) { 
TransactionSynchronizationManager.clear(); 
j 
if (status.isNewTransaction()) 1 
doCleanupA fterCompletion(status.getTransaction()); 
} 
if (status.getSuspendedResources() != null) { 
if (status.isDebug()) { 
logger.debug("Resuming suspended transaction after completion 
of inner 
transaction"); 
} 
// 结 束 之 前 事务 的 挂 起 状态 


resume(status.getTransaction(), (SuspendedResourcesHolder) 


status.getSuspended 


Resources()); 


} 

从 函数 中 得 知 ， 事 务 处 理 的 收尾 处 理工 作 包 括 如 下 内 容 。 

(1) 设置 状态 是 对 事务 信息 作 完 成 标识 以 避免 重复 调用 。 

(20 如 有 果 当 前 事务 是 新 的 同步 状态 ， 需 要 将 绑 定 到 当前 线程 的 事 
务 信 息 清 除 。 

(3) 如 果 是 新 事物 需要 做 些 清除 资源 的 工作 。 

protected void doCleanupA fterCompletion(Object transaction) { 











DataSourceTransactionObject txObject = 
(DataSourceTransactionObject) transaction; 
if (txObject.isNewConnectionHolder()) { 
/将 数据 库 连 接 从 当前 线程 中 解除 绑 定 





TransactionS ynchronizationManager.unbindResource(this.dataSource); 
} 
/释放 链接 
Connection con = txObject.getConnectionHolder().getConnection(); 
try { 
if (txObject.isMustRestoreAutoCommit()) { 
/恢复 数据 库 连 接 的 上 自动 提交 属性 
con.setAutoCommit(true); 
} 
/ 重 置 数据 库 连 接 


DataSourceUtils.resetConnectionAfterTransaction(con, 





txObject.getPrevious 


IsolationLevel()); 
} 
catch (Throwable ex) { 
logger.debug("Could not reset JOBC Connection after 
transaction", ex); 
} 
if (txObject.isNewConnectionHolder()) { 
if (logger.isDebugEnabled()) { 
logger.debug("Releasing JDBC Connection [" + con + "] after 
transaction"); 
j 
/如 果 当 前 事务 时 独立 的 新 创建 的 事务 则 在 事务 完成 时 释放 数 
据 库 连 接 
DataSourceUtils.releaseConnection(con, this.dataSource); 
} 
txObject.getConnectionHolder().clear(); 
j 
(4) 如果 在 事务 执行 前 有 事务 挂 起 ， 那 么 当前 事务 执行 结束 后 需 
要 将 挂 起 事务 恢复 。 


protected final void resume(Object transaction， 








SuspendedResourcesHolder resourcesHolder) 
throws TransactionException { 
if (resourcesHolder != null) { 
Object suspendedResources = 
resourcesHolder.suspendedResources; 
if (suspendedResources != null) { 


doResume(transaction, suspendedResources); 


} 

List<TransactionSynchronization> suspendedSynchronizations = 
resourcesHolder. 

suspendedS ynchronizations; 


if (suspendedSynchronizations != null) { 


TransactionS ynchronizationManager.setActualTransactionActive (resources 


Holder.wasActive); 


TransactionS ynchronizationManager.setCurrentTransactionIsolationLevel 


(resourcesHolder.isolationLevel); 


TransactionSynchronizationManager.setCurrentTransactionReadOnly 


(resourcesHolder.readOnly); 


TransactionS ynchronizationManager.setCurrentTransactionName 
(resourcesHolder.name); 


doResumeSynchronization(suspendedS ynchronizations); 


} 

10.3.3 事务 提交 

之 前 我 们 分 析 了 Spring 的 事务 异常 处 理 机 制 ， 那 么 事务 的 执行 并 没 
有 出 现任 何 的 异常 ， 也 就 意味 着 事务 可 以 走 正常 事务 提交 的 流程 了 。 

protected void commitTransactionA fterReturning(TransactionInfo 
txInfo) { 





if (txInfo != null && txInfo.hasTransaction()) { 
if (logger.isTraceEnabled()) { 
logger.trace("Completing transaction for [" * txInfo.getJoinpoint 


Identification() + "]"); 


txInfo.getTransactionManager().commit(txInfo.getTransactionStatus()); 
} 

} 

在 真正 的 数据 提交 之 前 ， 还 需要 做 个 判断 。 不 知道 大 家 还 有 没有 印 
象 ， 在 我 们 分 析 事 务 异 各 处 理 规则 的 时 候 ， 当 某 个 事务 既 没 有 保存 点 又 
不 是 新 事物 ，Spring 对 它 的 处 理 方 式 只 是 设置 一 个 回 滚 标识 。 这 个 回 滚 
标识 在 这 里 就 会 派 上 用 场 了 ， 主 要 的 应 用 场景 如 下 。 

菏 个 事务 是 另 一 个 事务 的 僚 入 事务 ， 但 是 ， 这 些 事务 又 不 在 Spring 
的 管理 范围 内 ， 或 者 无 法 设置 保存 点 ， 那 么 Spring 会 通过 设置 回 深 标 识 
的 方式 来 禁止 提交 。 首 先 当 某 个 嵌入 事务 发 生 回 滚 的 时 候 会 设置 回 滚 标 
识 ， 而 等 到 外 部 事务 提交 时 ， 一 旦 判断 出 当前 事务 流 被 设置 了 回 深 标 
识 ， 则 由 外 部 事务 来 统一 进行 整体 事务 的 回 滚 。 

所 以 ， 当 事务 没有 被 异常 捕获 的 时 候 也 并 不 意味 着 一 定 会 执行 提交 
的 过 程 。 


public final void commit(TransactionStatus status) throws 














TransactionException { 
if (status.isCompleted()) { 
throw new IllegalTransactionStateException( 
"Transaction is already completed - do not call commit or rollback 


more than once per transaction"); 


DefaultTransactionStatus defStatus = (DefaultTransactionStatus) 


status; 





// 如 果 在 事务 链 中 己 经 被 标记 回 深 ， 那 么 不 会 尝试 提交 事务 ， 直 
接 回 深 
if (defStatus.isLocalRollbackOnly()) { 
if (defStatus.isDebug()) 1 
logger.debug("Transactional code has requested rollback"); 
j 
processRollback(defStatus); 
return; 
j 
if (IshouldCommitOnGlobalRollbackOnly() && 
defStatus.isGlobalRollbackOnly()) 1 
if (defStatus.isDebug()) 1 
logger.debug(" Global transaction is marked as rollback-only but 
transactional code requested commit"); 
j 
processRollback(defStatus); 
if (status.isNewTransaction() || 
isFailEarlyOnGlobalRollbackOnly()) 1 
throw new UnexpectedRollbackException( 
"Transaction rolled back because it has been marked as 
rollback-only"); 
} 
return; 
j 
/处 理事 务 提交 


processCommit(defStatus); 
} 
而 当 事 务 执行 一 切 都 正常 的 时 候 ， 便 可 以 真正 地 进入 提交 流程 了 。 
private void processCommit(DefaultTransactionStatus status) throws 
TransactionException { 
try { 
boolean beforeCompletionInvoked = false; 
try { 
// 预 留 
prepareForCommit(status); 
/添加 的 TransactionSynchronization 中 的 对 应 方法 的 调用 
triggerBeforeCommit(status); 
/添加 的 TransactionSynchronization 中 的 对 应 方法 的 调用 
triggerBeforeCompletion(status); 
beforeCompletionInvoked = true; 
boolean globalRollbackOnly = false; 
if (status.isNewTransaction() || 
isFailEarlyOnGlobalRollbackOnly()) 1 
globalRollbackOnly = status.isGlobalRollbackOnly(); 
j 
if (status.hasSavepoint()) 1 
if (status.isDebug()) 1 
logger.debug("Releasing transaction savepoint"); 
j 
/如 果 存 在 保存 点 则 清除 保存 点 信息 


status.releaseHeldSavepoint(); 


else if (status.isNewTransaction()) { 
if (status.isDebug()) { 


logger.debug("Initiating transaction commit"); 


} 
/如 果 是 独立 的 事务 则 直接 提交 
doCommit(status); 

} 


if (globalRollbackOnly) { 
throw new UnexpectedRollbackException( 
"Transaction silently rolled back because it has been 


marked as rollback-only"); 


} 
catch (UnexpectedRollbackException ex) { 
triggerAfterCompletion(status, 
TransactionSynchronization.STATUS_ 
ROLLED BACK); 
throw ex; 
} 
catch (TransactionException ex) { 
if (isRollbackOnCommitFailure()) { 
doRollbackOnCommitException(status, ex); 
} 
else { 
triggerAfterCompletion(status, 
TransactionSynchronization.STATUS_ 
UNKNOWN); 


throw ex; 
} 
catch (RuntimeException ex) { 
if (!beforeCompletionInvoked) { 
triggerBeforeCompletion(status); 

} 
doRollbackOnCommitException(status, ex); 
throw ex; 

} 
catch (Error err) { 
if (!beforeCompletionInvoked) { 
/添加 的 TransactionSynchronization 中 的 对 应 方法 的 调用 
triggerBeforeCompletion(status); 

} 

/提交 过 程 中 出 现 异常 则 回 滚 
doRollbackOnCommitException(status, err); 
throw err; 

} 
try { 
/添加 的 TransactionSynchronization 中 的 对 应 方法 的 调用 
triggerAfterCommit(status); 
} 
finally { 
triggerAfterCompletion(status, 
TransactionSynchronization. STATUS . 
COMMITTED); 


} 
finally { 
cleanupAfterCompletion(status); 
j 
j 
在 提交 过 程 中 也 并 不 是 直接 提交 的 ， 而 是 考虑 了 诸多 的 方面 ， 符 合 
提交 的 条 件 如 下 。 
当 事 务 状 态 中 有 保存 点 信息 的 话 便 不 会 去 提交 事务 。 
当 事 务 非 新 事务 的 时 候 也 不 会 去 执行 提交 事务 操作 。 
此 条 件 主 要 考虑 内 和 能 事务 的 情况 ， 对 于 内 般 事 务 ， 在 Spring 中 正常 
的 处 理 方式 是 将 内 骨 事 务 开始 之 前 设置 保存 点 ， 一 旦 内 骨 事 务 出 现 异常 
便 根据 保存 点 信息 进行 回 深 ， 但 是 如 果 没 有 出 现 异 常 ， 内 骨 事 务 并 不 会 
单独 提交 ， 而 是 根据 事务 流 由 最 外 层 事 务 负责 提交 ， 所 以 如 果 当 前 存在 
保存 点 信息 便 不 是 最 外 层 事务 ， 不 做 保存 操作 ， 对 于 是 否 是 新 事务 的 判 
Ir to, EAE T E. 
如 果 程 序 流通 过 了 事务 的 层 层 把 和 天， 最 后 顺利 地 进入 了 提交 流程 ， 
那么 同样 ，Spring 会 将 事务 提交 的 操作 引导 至 底层 数据 库 连接 的 API， 
进行 事务 提交 。 


protected void doCommit(DefaultTransactionStatus status) { 




















DataSourceTransactionObject txObject = 
(DataSourceTransactionObject) status. 
getTransaction(); 
Connection con = txObject.getConnectionHolder().getConnection(); 
if (status.isDebug()) { 
logger.debug("Committing JDBC transaction on Connection [" + 


con 十 "J"; 


} 
try { 
con.commit(); 
} 
catch (SQLException ex) { 
throw new TransactionSystemException("Could not commit JDBC 
transaction", ex); 


} 


第 11 音 ”SpringMVC 


Spring 框架 提供 了 构建 Web 应 用 程序 的 全 功能 MVC 模 块 。 通 过 策略 
接口 ，Spring 框 架 是 高 度 可 配置 的 ， 而 且 文 持 多 种 视图 技术 ， 例 如 
JavaServer Pages (JSP) 技术 、Velocity、Tiles、iText 和 POI。Spring 
MVC 框 架 并 不 知道 使 用 的 视图 ， 所 以 不 会 强迫 您 只 使 用 JSP 技 术 。 
Spring MVC 分 离 了 控制 器 、 模 型 对 象 、 分 小 器 以 及 处 理 程序 对 象 的 角 
色 ， 这 种 分 离 让 它们 更 容易 进行 定制 。 

Spring 的 MVC 是 基于 Servlet 功 能 实现 的 ， 通 过 实现 Servlet 接 口 的 
DispatcherServlet 来 封装 其 核心 功能 实现 ， 通 过 将 请 求 分 派 给 处 理 程序 ， 
同时 融 有 可 配置 的 处 理 程序 映射 、 视 图 解析 、 本 地 语言 、 主 题解 析 以 及 
上 载 文件 支持 。 默 认 的 处 理 程序 是 非常 简单 的 Controller 接口 ， 只 有 一 
个 方法 ModelAndView handleRequest(request, response)。Spring 提 供 了 一 
个 控制 器 层次 结构 ， 可 以 派生 子 类 。 如 果 应 用 程序 需要 处 理 用 户 输入 表 
单 ， 那 么 可 以 继承 AbstractFormController。 如 果 需 要 把 多 页 输入 处 理 到 
一 个 表单 ， 那 么 可 以 继承 AbstractWizardFormController。 

SpringMVC 或 者 其 他 比较 成 熟 的 MVC 框 架 而 言 ， 解 决 的 问题 无 外 











FUP LR 
(1) 将 Web 页 面 的 请 求 传 给 服务 器 。 
C2) 根据 不 同 的 请 求 处 理 不 同 的 逻辑 单元 。 
(3) 返回 处 理 结 果 数 据 并 跳 转 至 啊 应 的 页 面 。 
我 们 首先 通过 一 个 简单 示例 来 快速 回顾 SpringMVC 的 使 用 。 


11.1 SpringMVC 快 速 体 验 


(1) 配置 web.xml。 

一 个 Web 中 可 以 没有 web.xml 文 件 ， 也 就 是 说 ，web.xml 文 件 并 不 是 
Web 工 程 必 须 的 。web.xml 文 件 用 来 初始 化 配置 信息 : 比如 Welcome 页 
面 、servlet、servlet-mapping、filter、listener、 启 动 加 载 级 别 等 。 但 是 ， 
SpringMVC 的 实现 原理 是 通过 Servlet 拦 截 所 有 URL 来 达到 控制 的 目的 ， 
所 以 web.xml 的 配置 是 必须 的 。 


<?xml version="1.0" encoding="UTF-8"?> 





<web-app id="WebApp_ID" version="2.5" 
xmins-"http://java.sun.com/xml/ns/javaee" 
xmins:xsi-"http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation-"http://java.sun. 
com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web- 
app. 2 5.xsd"» 
<display-name>Springmvc</display-name> 
<!-- 使 用 ContextLoaderListener 配 置 时 ， 需 要 告诉 它 Spring 配 置 
文件 的 位 置 --> 
<context-param> 
<param-name>contextConfigLocation</param-name> 


<param-value>classpath:applicationContext.xml</param-value> 


</context-param> 
<!-- SpringMVC 的 前 端 控制 器 --> 
<!-- 当 DispatcherServlet 载 入 后 ， 它 将 从 一 个 XML 文件 中 载 入 
Spring 的 应 用 上 下 文 ， 该 XML 文件 的 名 
字 取 决 于 <servlet-name> --> 


<!-- 这 里 DispatcherServlet 将 试图 从 一 个 叫做 Springmvc-servlet.xml 
的 文件 中 载 入 应 用 上 下 文 ， 其 


默认 位 于 WEB-INF 目 录 下 --> 


<servlet> 


<servlet-name>Springmvc</servlet-name> 
<servlet- 


class>org.Springframework.web.servlet.DispatcherServlet</servlet-class> 


<load-on-startup>1</load-on-startup> 
</servlet> 


<servlet-mapping> 
<servlet-name>Springmvc</servlet-name> 


<url-pattern>*.htm</url-pattern> 


</servlet-mapping> 
<!-- Ac EP CaM A ait --> 


<!-- 上 下 文 载 入 器 载 入 除 DispatcherServlet 载 入 的 配置 文件 之 外 
的 其 它 上 下 文 配置 文件 --> 


<!-- 最 常用 的 上 下 文 载 入 器 是 一 个 Servlet 监 昕 器 ， 其 名 称 为 
ContextLoaderListener --> 
<listener> 
<listener- 


class>org.Springframework.web.context.ContextLoaderListener 
</listener-class> 


</listener> 
</web-app> 
Spring 的 MVC 之 所 以 必须 要 配置 web.xml， 其 实 最 关键 的 是 要 配置 
两 个 地 方 。 
contextConfigLocation: Spring 的 核心 惑 是 配置 文件 ， 可 以 说 配置 文 
件 是 Spring 中 必 不 可 少 的 东西 ， 而 这 个 参数 就 是 使 web 与 Spring 的 配置 
文件 相 结 合 的 一 个 关键 配置 。 
DispatcherServlet: 包含 了 SpringMVC 的 请 求 逻 辑 ，Spring 使 用 此 类 
拦截 Web 请 求 并 进行 相应 的 还 辑 处 理 。 
(2) 创建 Spring 配置 文件 applicationContext.xml。 
<?xml version="1.0" encoding="UTF-8"?> 
«beans xmlns-"http://www.Springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 


xmins:tx-"http://www.Springframework.org/schema/tx" 


xsi:schemaLocation-"http://www.Springframework.org/schema/beans 
http://www.Springframework.org/schema/beans/Spring-beans-2.5.xsd 
http://www.Springframework.org/schema/tx 
http://www.Springframework.org/schema/tx/Spring-tx-2.5.xsd"> 
<bean id="viewResolver" 
class="org.Springframework.web.servlet.view. Internal Resource 
ViewResolver "> 
<property name-"prefix" value="/WEB-INF/jsp/"/> 
<property name="suffix" value=".jsp"/> 
</bean> 
</beans> 


InternalResourceViewResolver 是 一 个 辅助 Bean， 会 在 ModelAndView 


返回 的 视图 名 前 加 上 prefix 指定 的 前 级， 再 在 最 后 加 上 suffix 指定 的 后 
级 ， 例 如 : 由 于 XXController 返回 的 ModelAndView 中 的 视图 名 是 
testview， 故 该 视图 解析 器 将 在 /WEB-INF/jsp/testview.jsp 处 查找 视图 。 
(3) 创建 model。 
模型 对 于 SpringMVC 来 说 并 不 是 必 不 可 少 ， 如 果 处 理 程 序 非常 简 
单 ， 完 全 可 以 忽略 。 模 型 创建 主要 的 目的 就 是 承载 数据 ， 使 数据 传输 更 
加 方便 。 
public class User { 
private String username; 
private Integer age; 
public String getUsername() { 
return username; 
} 
public void setUsername(String username) { 
this.username = username; 
} 
public Integer getAge() { 
return age; 
} 
public void setAge(Integer age) { 


this.age = age; 


} 
(4) 4!) controller. 
Peril a Ab Webi ak, BESS Hill as ABT ND 7I ER A 
public class UserController extends AbstractController { 
@Override 


protected ModelAndView handleRequestInternal(HttpServletRequest 
arg0, HttpServletResponse 
arg1) throws Exception { 
List<User> userList = new ArrayList<User>(); 
User userA = new User(); 
User userB = new User(); 
userA.setUsername("3k ="); 
userA.setAge(27); 
userB.setUsername("2= /U"); 
userB.setAge(37); 
userList.add(userA ); 
userList.add(userB); 
return new ModelAndView("userlist", "users", userList); 
} 


} 
在 请 求 的 最 后 返回 了 ModelAndView 类 型 的 实例 。ModelAndView 类 


在 SpringMVC 中 占有 很 重要 的 地 位 ， 控制 器 执行 方法 都 必须 返回 一 个 
ModelAndView，ModelAndView 对 象 保存 了 视图 以 及 视图 显示 的 模型 数 
据 ， 例 如 其 中 的 参数 如 下 。 

第 一 个 参数 userlist， 视图 组 件 的 逻辑 名 称 。 这 里 视图 的 多 辑 名 称 惑 
是 userlist， 视 图 解析 器 会 使 用 该 名 称 碍 找 实际 的 View 对 象 。 

第 二 个 参数 users: 传递 给 视图 的 ， 模 型 对 象 的 名 称 。 

第 三 个 参数 userList: 传递 给 视图 的 ， 模 型 对 象 的 值 。 

(5) 创建 视图 文件 userlist.jsp。 

<%@ page language="java" pageEncoding="UTF-8"%> 

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%> 

<h2>This is SpringMVC demo page</h2> 


<c:forEach items="${users}" var="user"> 
<c:out value="$ {user.username }"/><br/> 
«c:out value="$ {user.age }"/><br/> 
</c:forEach> 
视图 文件 用 于 展现 请 求 处 理 结 果 ， 通 过 对 JSTL 的 文 持 ， 可 以 很 方便 
地 展现 在 控制 器 中 放 入 ModelAndView 中 的 处 理 结 果 数 据 。 
(6) 创建 Servlet 配 置 文件 Spring-servlet.xml。 
<?xml version="1.0" encoding="UTF-8"?> 
«beans xmlns="http://www.Springframework.org/schema/beans" 
xmins:xsi-"http://www.w3.org/2001/XMLSchema-instance" 
xmins:tx-"http://www. Spring 


framework. org/schema/tx" 


xsi:schemaLocation="http://www.Springframework.org/schema/beans 
http://www.Springframework.org/schema/beans/Spring-beans-2.5.xsd 
http://www.Springframework.org/schema/tx 
http://www.Springframework.org/schema/tx/Spring-tx-2.5.xsd"> 
<bean id="simpleUrlMapping" 
class="org.Springframework.web.servlet.handler.SimpleUrlHandlerMapping" 
<property name="mappings"> 
<props> 
<prop key="/userlist.htm">userController</prop> 
</props> 
</property> 
</bean> 


<!-- 这 里 的 id="userController" Xt Dv fy £ «bean 


id="simpleUrlMapping"> 中 的 <prop> 里 面 的 
Value --> 
<bean id="userController" class-"test.controller. UserController" /> 
</beans> 
为 SpringMVC 是 基于 Servlet 的 实现 ， 所 以 在 Web 局 动 的 时 候 ， 服 
务 器 会 首先 党 试 加 载 对 应 于 Servlet 的 配置 文件 ， 而 为 了 让 项 目 更 加 模块 
化 ， 通 第 我 们 将 Web 部 分 的 配置 都 存放 于 此 配置 文件 中 。 
至 此 ， 已 经 完成 了 SpringMVC 的 搭建 ， 局 动 服务 器 ， 输 入 网 址 
http://localhost:8080/Springmvc/userlist.htm 。 
看 到 了 服务 器 返回 界面 ， 如 图 11-1 所 示 。 





Æ http://localhost:S080/springmvc/userlist.htm 





This is SpringMVC demo page 





图 11-1 Spring MVC 快 速 体验 
11.2 ContextLoaderListener 


对 于 SpringMVC 功 能 实现 的 分 析 ， 我 们 首先 从 web.xml 开 始 ， 在 
web.xml 文 件 中 我 们 首先 配置 的 承 是 ContextLoaderListener， 那 么 它 所 提 
供 的 功能 有 哪些 又 是 如 何 实现 的 呢 ? 

当 使 用 编程 方式 的 时 候 我 们 可 以 直接 将 Spring 配置 信息 作为 参数 传 
入 Spring 容 器 中 ， 如 


ApplicationContext ac=new 





ClassPathXmlApplicationContext(“applicationContext.xm1”); 

但 是 在 Web 下， 我们 需要 更 多 的 是 与 Web 环境 相互 结合 ， 通 常 的 
办 法 是 将 路 径 以 context-param 的 方式 注册 并 使 用 ContextLoaderListener 进 
行 监 听 读 取 。 

ContextLoaderListener 的 作用 就 是 启动 Web 容 器 时 ， 自 动 装配 
ApplicationContext 的 配置 信息 。 因 为 它 实 现 了 ServletContextListener 这 个 
接口 ， 在 web.xml 配 置 这 个 监听 器 ， 局 动容 器 时 ， 就 会 默认 执行 它 实 现 
的 方法 ， 使 用 ServletContextListener 接 口 ， 开 发 者 能 够 在 为 客户 端 请 求 
提供 服务 之 前 向 ServletContext 中 添加 任意 的 对 象 。 这 个 对 象 在 
ServletContext 启 动 的 时 候 被 初始 化 ， 然 后 在 ServletContext 整 个 运行 期 间 
都 是 可 见 的 。 

每 一 个 Web 应 用 都 有 一 个 ServletContext 与 之 相关 联 。ServletContext 
对 象 在 应 用 局 动 时 被 创建 ， 在 应 用 关闭 的 时 候 被 销毁 。ServletContext 在 
全 局 范围 内 有 有效， 类似 于 应 用 中 的 一 个 全 局 变量 。 

在 ServletContextListener 中 的 核心 逻辑 便 是 初始 化 
WebApplicationContext 实例 并 存放 至 ServletContext 中 。 


11.2.1 ServletContextListener 的 使 用 


正式 分 析 代 码 前 我 们 同样 还 是 首先 了 解 ServletContextListener 的 使 
用 。 











(1) 创建 自 定 义 ServletContextListener。 
首先 我 们 创建 ServletContextListener， 目标 是 在 系统 启动 时 添加 自 
定义 的 属性 ， 以 便于 在 全 局 范围 内 可 以 随时 调用 。 系 统 局 动 的 时 候 会 调 
用 ServletContextListener 实现 类 的 contextInitialized 方 法 ， 所 以 需要 在 这 
个 方法 中 实现 我 们 的 初始 化 逻辑 。 


public class MyDataContextListener implements ServletContextListener 


private ServletContext context = null; 

public MyDataContextListener () { 

} 

/该 方法 在 ServletContext 局 动 之 后 被 调用 ， 并 准备 好 处 理 客户 端 
WR 

public void contextInitialized(ServletContextEvent event) { 


this.context = event.getServletContext(); 
// 通 过 你 可 以 实现 自己 的 逻辑 并 将 结果 记录 在 属性 中 
context = setAttribute(“myData”,”this is myData"); 
} 
/这 个 方法 在 ServletContext 将 要 关闭 的 时 候 调 用 
public void contextDestroyed(ServletContextEvent event){ 


this.context = null; 


} 
(2) TEES Ur ds 
在 web.xml 文 件 中 需要 注册 自 定义 的 监听 器 。 
<listener> 
com.test. MyDataContextListener 
</listener> 
(3) 测试 。 
一 旦 Web 应 用 局 动 的 时 候 ， 我 位 能 在 任意 的 Servlet 或 者 JSP 中 通 
过 下 面 的 方式 获取 我 们 初始 化 的 参数 ， 如 下 : 
String myData = (String) getServletContext().getAttribute(“myData”); 


11.2.2 Sprin JContextLoaderListener 


分 析 了 ServletContextListener 的 使 用 方式 后 再 来 分 析 Spring 中 的 


ContextLoaderListener 的 实现 就 容易 理解 的 多 ， 虽 然 
ContextLoaderListener 实 现 的 逻辑 要 复杂 的 多 ， 但 是 大 致 的 套路 还 是 万 
变 不 离 其 宗 。 
ServletContext 启 动 之 后 会 调用 ServletContextListener 的 
contextInitialized 方 法 ， 那 么 ， 我 们 区 从 这 个 函数 开始 进行 分 析 。 
public void contextInitialized(ServletContextEvent event) { 
this.contextLoader = createContextLoader(); 
if (this.contextLoader == null) { 
this.contextLoader = this; 
} 
/初始 化 WebApplicationContext 


this.contextLoader.initWebApplicationContext(event.getServletContext()); 

} 

这 里 涉及 了 一 个 常用 类 WebApplicationContext: 在 Web 应 用 中 ， 我 
们 会 用 到 WebApplication Context，WebApplicationContext 继 承 自 
ApplicationContext， 在 ApplicationContext 的 基础 上 又 追加 了 一 些 特定 于 
Web 的 操作 及 属性 ， 非 常 类 似 于 我 们 通过 编程 方式 使 用 Spring 时 使 用 
的 ClassPathXmlApplicationContext 类 提供 的 功能 。 继 续 跟 踪 代 码 : 

public WebApplicationContext 
initWebApplicationContext(ServletContext servletContext) { 

if 
(servletContext.getAttribute( WebApplicationContext.ROOT_ WEB_APPLIC, 
CONTEXT_ATTRIBUTE) != null) { 
/web.xml 中 存在 多 次 ContextLoader 定 义 
throw new IllegalStateException( 


"Cannot initialize context because there is already a root 


application context present - " + 
web.xml!"); 


"check whether you have multiple ContextLoader* definitions in 


your 


} 
Log logger = LogFactory.getLog(ContextLoader.class); 


servletContext.log("Initializing Spring root 
WebAp pplicationContext"); 
if (logger.isInfoEnabled()) 1 
logger.info("Root WebApplicationContext: initialization started"); 


} 


long startTime = System.currentTimeMillis(); 
try { 
// Store context in local instance variable, to guarantee that 
// it is available on ServletContext shutdown. 
if (this.context == null) { 
/初始 化 context 


this.context = createWebApplicationContext(servletContext); 


} 
if (this.context instanceof ConfigurableWebApplicationContext) { 


configureAndRefreshWebApplicationContext((ConfigurableWebApplication 


Context)this.context, servletContext); 


} 
// 记 录 在 servletContext 中 


servletContext.setAttribute( WebApplicationContext.ROOT_WEB_APPLICA 


CONTEXT_ATTRIBUTE, this.context); 
ClassLoader ccl = 
Thread.currentThread().getContextClassLoader(); 
if (ccl == ContextLoader.class.getClassLoader()) { 
currentContext = this.context; 
} 
else if (ccl != null) { 
currentContextPerThread.put(ccl, this.context); 
} 
if (logger.isDebugEnabled()) 1 
logger.debug(" Published root WebApplicationContext as 
ServletContext 


attribute with name [" + 


WebApplicationContex.ROOT WEB APPLICATION CONTEXT ATTRI 
+"); 
} 
if (logger.isInfoEnabled()) { 
long elapsedTime = System.currentTimeMillis() - start l'ime; 
logger.info(" Root WebApplicationContext: initialization 
completed in 
"+ elapsedTime + " ms"); 
j 
return this.context; 
j 
catch (RuntimeException ex) { 


logger.error(" Context initialization failed", ex); 


servletContext.setAttribute( WebApplicationContext.ROOT_WEB_APPLICA 
CONTEXT_ATTRIBUTE, ex); 
throw ex; 
} 
catch (Error err) { 


logger.error(" Context initialization failed", err); 


servletContext.setAttribute(WebApplicationContex.ROOT WEB APPLICA 
CONTEXT ATTRIBUTE, err); 


throw err; 


} 

initWebApplicationContext 函数 主要 是 体现 了 创建 
WebApplicationContext 实例 的 一 个 功能 架构 ， 从 函数 中 我 们 看 到 了 初始 
化 的 大 致 步骤 。 

(1) WebApplicationContext 存 在 性 的 验证 。 

在 配置 中 只 允许 声明 一 次 ServletContextListener， 多 次 声明 会 扰乱 
Spring 的 执行 逻辑 ， 所 以 这 里 首先 做 的 就 是 对 此 验证 ， 在 Spring PWR 
创建 WebApplicationContext 实例 会 记录 在 ServletContext 中 以 方便 全 局 
调用 ， 而 使 用 的 key 就 是 
WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRI 
所 以 验证 的 方式 就 是 查看 ServletContext 实 例 中 是 否 有 对 应 key 的 属性 。 

(2) 创建 WebApplicationContext 实 例 。 

如 果 通 过 验证 ， 则 Spring 将 创建 WebApplicationContext 实例 的 工 
作 委 托 给 了 create WebApplicationContext 函 数 。 

protected WebApplicationContext 





createWebApplicationContext(ServletContext sc) { 

Class<?> contextClass = determineContextClass(sc); 

if 
(!ConfigurableWebApplicationContext.class.isAssignableFrom(contextClass) 
{ 


throw new ApplicationContextException(" Custom context class [" 


contextClass.getName() + 
"| is not of type [" + 
ConfigurableWebApplicationContext.class.getName() 
TR 
j 
ConfigurableWebApplicationContext wac = 
(ConfigurableWebApplicationContext) BeanUtils.instantiateClass 
(contextClass); 
return wac; 
j 
protected Class<?> determineContextClass(ServletContext 
servletContext) { 
//CONTEXT CLASS PARAM = "contextClass"; 
String contextClassName = 
servletContext.getInitParameter(CONTEXT CLASS PARAM); 
if (contextClassName != null) 1 
try 1 
return ClassUtils.forName(contextClassName, 
ClassUtils.getDefaultClass 
Loader()); 


} 
catch (ClassNotFoundException ex) { 
throw new ApplicationContextException( 
"Failed to load custom context class [" + contextClassName + 


"s ex); 


} 
else { 
contextClassName = 
defaultStrategies.getProperty(WebApplicationContext. 
class.getName()); 
try { 
return ClassUtils.forName(contextClassName, 
ContextLoader.class. 
getClassLoader()); 
j 
catch (ClassNotFoundException ex) 1 
throw new ApplicationContextException( 


"Failed to load default context class [" + contextClassName 


+ "J", ex); 
} 
} 
} 
其 中 ， 在 ContextLoader 类 中 有 这 样 的 静态 代码 块 : 
static { 


// Load default strategy implementations from properties file. 


// This is currently strictly internal and not meant to be customized 


// by application developers. 
try { 
//DEFAULT STRATEGIES PATH = "ContextLoader.properties" 
ClassPathResource resource = new 
ClassPathResource(DEFAULT STRATEGIES PATH, 
ContextLoader.class); 
defaultStrategies — 
PropertiesLoaderUtils.loadProperties(resource); 
j 
catch (IOException ex) 1 
throw new IllegalStateException(" Could not load 
‘ContextLoader.properties': 


" + ex.getMessage()); 


} 

根据 以 上 静态 代码 块 的 内 容 ， 我 们 推断 在 当前 类 ContextLoader 同 
样 目录 下 必定 会 存在 属性 文件 ContextLoader.properties， 查 看 后 果然 存 
在 ， 内 容 如 下 : 


org.Springframework.web.context.WebApplicationContext=org.Springfr 





support.XmlWebApplicationContext 
综合 以 上 代码 分 析 ， 在 初始 化 的 过 程 中 ， 程 序 首 先 会 读 取 
ContextLoader 类 的 同 目录 下 的 属性 文件 ContextLoader.properties， 并 根 
据 其 中 的 配置 提取 将 要 实现 WebApplicationContext 接 口 的 实现 类 ， 并 根 
据 这 个 实现 类 通过 反射 的 方式 进行 实例 的 创建 。 
(3) 将 实例 记录 在 servletContext 中 。 
(4) 上 映射 当前 的 类 加 载 器 与 创建 的 实例 到 全 局 变量 
currentContextPerThread 中 。 

















11.3 DispatcherServlet 


在 Spring 中 ，ContextLoaderListener 只 是 辅助 功能 ， 用 于 创建 
WebApplicationContext 类 型 实例 ， 而 真正 的 逻辑 实现 其 实 是 在 
DispatcherServlet 中 进行 的 ，DispatcherServlet 是 实现 servlet 接 口 的 实现 
类 。 

servlet 是 一 个 Java 编写 的 程序 ， 此 程序 是 基于 HTTP 协议 的 ， 在 服 
务 器 问 运 行 的 〈 如 Tomcat) ， 是 按照 servlet 规 范 编写 的 一 个 Java 类 。 主 
要 是 处 理 客户 端的 请 求 并 将 其 结果 发 送 到 客户 端 。servlet 的 生命 周期 是 
由 servlet 的 容器 来 控制 的 ， 它 可 以 分 为 3 个 阶段 : 初始化、 运行 和 销毁 。 

(1) 初始 化 阶段 。 

servlet 容 器 加 载 servlet 类 ， 把 servlet 类 的 .class 文 件 中 的 数据 读 到 内 存 
中 。 

servlet 容 器 创建 一 个 ServletConfig 对 象 。ServletConfig 对 象 包含 了 
servlet 的 初始 化 配置 信息 。 

servlet 容 器 创建 一 个 servlet 对 象 。 

servlet 容 器 调用 servlet 对 象 的 init 方 法 进行 初始 化 。 

(2) 运行 阶段 。 

当 servlet 容器 接收 到 一 个 请 求 时 ，servlet 容器 会 针对 这 个 请 求 创建 
servletRequest 和 servletResponse 对 象 ， 然 后 调用 service 方 法 。 并 把 这 两 
个 参数 传递 给 service 方 法 。service 方 法 通过 servletRequest 对 象 获得 请 求 
的 信息 。 并 处 理 该 请 求 。 再 通过 servletResponse 对 象 生成 这 个 请 求 的 响 
应 结果 。 然 后 销毁 servletRequest 和 servletResponse 对 象 。 我 们 不 管 这 
个 请 求 是 post 提 交 的 还 是 get 提 交 的 ， 最 终 这 个 请 求 都 会 由 service 方 法 来 
处 理 。 

(3) 销毁 阶段 。 














当 Web 应 用 被 终止 时 ，servlet 容 器 会 先 调用 servlet 对 象 的 destrory 方 
法 ， 然 后 再 销毁 servlet 对 象 ， 同 时 也 会 销毁 与 servlet 对 象 相 关联 的 
servletConfig 对 象 。 我 们 可 以 在 destroy 方 法 的 实现 中 ， 释 放 servlet 所 占用 
的 资源 ， 如 关闭 数据 库 连 接 ， 关 闭 文件 输入 输出 流 等 。 

servlet 的 框架 是 由 两 个 Java 包 组 成 : javax.servlet 和 
javax.servlet.http。 在 javax.servlet 包 中 定义 了 所 有 的 servlet 类 都 必须 实现 
或 扩展 的 通用 接口 和 类 ， 在 javax.servlet.http 包 中 定义 了 采用 HTTP 通 信 
协议 的 HttpServlet 类 。 

servlet 被 设计 成 请 求 驱动 ，servlet 的 请 求 可 能 包含 多 个 数据 项 ， 当 
Web 容器 接收 到 某 个 servlet 请 求 时 ，servlet 把 请 求 封装 成 一 个 
HttpServletRequest 对 象 ， 然 后 把 对 象 传 给 servlet 的 对 应 的 服务 方法 。 

HTTP 的 请 求 方式 包括 delete、get、options、post、put 和 trace， 在 
HttpServlet 类 中 分 别提 供 了 相应 的 服务 方法 ， 它 们 是 doDelete()、 
doGet()、doOptions()、doPost()、doPutO 和 doTrace()。 


11.3.1 servlet 的 使 用 


我 们 同样 还 是 以 最 简单 的 servlet 来 快速 体验 其 用 法 。 
(1) 建立 servlet。 
public class MyServlet extends HttpServlet{ 





public void init()1 
System.out.printIn("this is init method"); 
j 
public void doGet(HttpServletRequest request, HttpServletResponse 
response)1 
handleLogic(request,response); 
j 
public void doPost(HttpServletRequest request, HttpServletResponse 


response){ 
handleLogic(request,response); 
} 
private void handleLogic(HttpServletRequest request, 
HttpServletResponse response) { 
System.out.printin("handle myLogic"); 
ServletContext sc = getServletContext(); 
RequestDispatcher rd = null; 
rd = sc.getRequestDispatcher("/index.jsp"); // 定 问 的 页 面 
try { 
rd.forward(request, response); 
} catch (ServletException | IOException e) { 
e.printStackTrace(); 


} 

REE EV), FLERE. SPP AL J Minit TIE A get/post WIE AY Ab 
理 ，init 方 法 保证 在 在 servlet 加 载 的 时 候 能 做 一 些 逻 辑 操作 ， 而 
HttpServlet 类 则 会 帮助 我 们 根据 方法 类 型 的 不 同 而 将 逻辑 引入 不 同 的 函 
数 。 在 子 类 中 我 们 只 需要 重 写 对 应 的 函数 逻辑 便 可 ， 如 以 上 代码 重 写 了 
doGet 和 doPost 方 法 并 将 逻辑 处 理 部 分 引导 人 至 handleLogic 隙 数 中 ， 最 后 ， 
叉 将 页 面 跳 转 至 index.jsp。 

(2) 添加 配置 。 
为 了 使 servlet 能 够 正常 使 用 ， 需 要 在 web.xml 文 件 中 添加 以 下 配置 : 


<servlet> 








<servlet-name>myservlet</servlet-name> 
<servlet-class>test.servlet.MyServlet</servlet-class> 


<load-on-startup>1</load-on-startup> 


</servlet> 

<servlet-mapping> 
<servlet-name>myservlet</servlet-name> 
<url-pattern>*.htm</url-pattern> 


</servlet-mapping> 


配置 后 便 可 以 根据 对 应 的 配置 访问 啊 应 的 路 径 了 。 
11.3.2 DispatcherServlet 的 初始 


通过 上 面 的 实例 我 们 了 解 到 ， 在 servlet 初 始 化 阶段 会 调用 其 init 方 
法 ， 所 以 我 们 首先 要 查看 在 DispatcherServlet 中 是 否 重 写 了 init 方 法 。 我 
们 在 其 父 类 HttpServletBean 中 找到 了 该 方法 。 
public final void init() throws ServletException { 
if (logger.isDebugEnabled()) { 
logger.debug("Initializing servlet " + getServletName() + """); 
} 
try { 
/解析 init-param 并 封装 只 pvs 中 
PropertyValues pvs = new 
ServletConfigProperty Values(getServletConfig(), 
this.requiredProperties); 
// 将 当前 的 这 个 Servlet 类 转化 为 一 个 BeanWrapper, 从 而 能 够 以 
Spring 的 方式 来 对 init-param 
的 值 进行 注 
BeanWrapper bw = 
PropertyAccessorFactory.forBeanPropertyAccess(this); 
ResourceLoader resourceLoader = new 


ServletContextResourceLoader 


(getServletContext()); 
/注册 自 定 义 属 性 编辑 器 ， 一 旦 遇 到 Resource 类 型 的 属性 将 会 
使 用 ResourceEditor 进 行 解 析 


bw.registerCustomEditor(Resource.class, new 





ResourceEditor(resourceL oader, 
this.environment)); 
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initBeanWrapper(bw); 
/属性 注入 
bw.setProperty Values(pvs, true); 
} 
catch (BeansException ex) { 
logger.error("Failed to set bean properties on servlet ' + 
getServletName() 
me 
throw ex; 
} 
// 留 给 子 类 扩展 
initServletBean(); 
if (logger.isDebugEnabled()) { 
logger.debug(" Servlet " + getServletName() + ' configured 
successfully"); 
j 
j 
DipatcherServlet 的 初始 化 过 程 主 要 是 通过 将 当前 的 servlet 类 型 实例 
转换 为 BeanWrapper 类 型 实例 ， 以 便 使 用 Spring 中 提供 的 注入 功能 进行 
对 应 属性 的 注入 。 这 些 属性 如 contextAttribute、 contextClass、 


nameSpace、contextConfigLocation 等 ， 都 可 以 在 web.xml 文 件 中 以 初始 
化 参数 的 方式 配置 在 servlet 的 声明 中 。DispatcherServlet 继 承 日 
FrameworkServlet，FrameworkServlet 类 上 包含 对 应 的 同名 属性 ，Spring 
会 保证 这 些 参数 被 注入 到 对 应 的 值 中 。 属 性 注入 主要 包含 以 下 几 个 步 
JE. 

1. 封装 及 验证 初始 化 参数 

ServletConfigPropertyValues 除 了 封装 属性 外 还 有 对 属性 验证 的 功 


能 。 
public ServletConfigPropertyValues(ServletConfig config, Set<String> 
requiredProperties) 
throws ServletException { 
Set<String> missingProps = (requiredProperties != null && 
!requiredProperties. 


isEmpty()) ? 
new HashSet<String>(requiredProperties) : null; 
Enumeration en = config.getInitParameterNames(); 
while (en.hasMoreElements()) { 
String property = (String) en.nextElement(); 
Object value = config.getInitParameter(property); 
addPropertyV alue(new PropertyValue(property, value)); 
if (missingProps != null) { 


missingProps.remove(property); 


} 
// Fail if we are still missing properties. 
if (missingProps != null && missingProps.size() > 0) { 


throw new ServletException( 


"Initialization from ServletConfig for servlet "" + 
config.getServlet 

Name() + 

failed; the following required properties were missing: " + 


wo" 


StringUtils.collectionToDelimitedString(missingProps, ", ")); 


} 

从 代码 中 得 知 ， 封 装 属 性 主要 是 对 初始 化 的 参数 进行 封装 ， 也 就 是 
servlet 中 配置 的 <init-param> 中 配置 的 封装 。 当 然 ， 用 户 可 以 通过 对 
requiredProperties 参 数 的 初始 化 来 强制 验证 某 些 属性 的 必要 性 ， 这 样 ， 
在 属性 封装 的 过 程 中 ， 一 旦 检测 到 requiredProperties 中 的 属性 没有 指定 
初始 值 ， 就 会 抛 出 异常 。 

2. 将 当前 servlet 实 例 转 化 成 BeanWrapper 实 例 

PropertyAccessorFactory.forBeanPropertyAccess 是 Spring 中 提供 的 工 
上 其 方法， 主要 用 于 将 指定 实例 转化 为 Spring 中 可 以 处 理 的 BeanWrapper 
类 型 的 实例 。 

3. 注册 相对 于 Resource 的 属性 编辑 器 

属性 编辑 器 ， 我 们 在 上 文中 已 经 介绍 并 且 分 析 过 其 原理 ， 这 里 使 用 
属性 编辑 器 的 目的 是 在 对 当前 实例 C DispatcherServlet ) 属性 注入 过 程 
中 一 旦 过 到 Resource 类 型 的 属性 就 会 使 用 ResourceEditor 去 解析 。 

4. 属性 注入 

BeanWrapper 为 Spring 中 的 方法 ， 文 持 Spring 的 自动 注入 。 其 实 我 们 
最 常用 的 属性 注入 无 非 是 contextAttribute、contextClass、nameSpace、 
contextConfigLocation 等 属性 。 

5. servletBean 的 初始 化 

在 ContextLoaderListener 加 载 的 时 候 已 经 创建 了 
WebApplicationContext 实 例 ， 而 在 这 个 函数 中 最 重要 的 就 是 对 这 个 实例 








进行 进一步 的 补充 初始 化 。 
Ak 4: FE initServletBean(). 3028FrameworkServlet#2 mi J 
HttpServletBean 中 的 initServlet Bean 函 数 ， 如 下 : 
protected final void initServletBean() throws ServletException { 
getServletContext().log("Initializing Spring FrameworkServlet ' + 
getServlet 
Name() + ™"); 
if (this. logger.isInfoEnabled()) { 


this.logger.info("FrameworkServlet " + getServletName() + ”: 


initialization 
started"); 
} 
long startTime = System.currentTimeMillis(); 
try { 
this.webApplicationContext = initWebApplicationContext(); 
MBit NF ZB hi 
initFrameworkServlet(); 
} 


catch (ServletException ex) { 
this.logger.error(" Context initialization failed", ex); 
throw ex; 

} 

catch (RuntimeException ex) { 
this.logger.error(" Context initialization failed", ex); 
throw ex; 

} 

if (this. logger.isInfoEnabled()) { 


long elapsedTime = System.currentTimeMillis() - startTime; 
this.logger.info("FrameworkServlet ' + getServletName() + ": 
initialization completed in " + 


elapsedTime + " ms"); 


} 

上 面 的 函数 设计 了 计时 器 来 统计 初始 化 的 执行 时 间 ， 而 且 提 供 了 一 
个 扩展 方法 initFrameworkServlet() 用 于 子 类 的 窗 新 操作 ， 而 作为 关键 的 
初始 化 逻辑 实现 委托 给 了 initWebApplicationContext()。 





11.3.3 WebApplicationContext 的 初始 


initWebApplicationContext 函数 的 主要 工作 束 是 创建 或 刷新 
WebApplicationContext 实例 并 对 servlet 功 能 所 使 用 的 变量 进行 初始 化 。 
Protected WebApplicationContext initWebApplicationContext() { 
WebApplicationContext rootContext = 


WebApplicationContextUtils.getWebApplicationContext(getServletContext() 
WebApplicationContext wac = null; 
if (this.webApplicationContext != null) { 
//context 实 例 在 构造 函数 中 被 注入 
wac = this.webApplicationContext; 
if (wac instanceof ConfigurableWebApplicationContext) { 
ConfigurableWebApplicationContext cwac = 
(ConfigurableWebApplication 
Context) wac; 
if (!cwac.isActive()) 1 


if (cwac.getParent() == null) 1 


cwac.setParent(rootContext); 
} 
/刷新 上 下 文 环 境 
configureAndRefreshWebApplicationContext(cwac); 


} 

if (wac == null) { 

/根据 contextAttribute 属 性 加 载 WebApplicationContext 
wac = findWebApplicationContext(); 

} 

if (wac == null) { 


// No context instance is defined for this servlet -> create a local 


one 
wac = createWebApplicationContext(rootContext); 
} 
if (!this.refreshEventReceived) { 
// Either the context is not a ConfigurableApplicationContext with 
refresh 
// support or the context injected at construction time had already 
been 


// refreshed -> trigger initial onRefresh manually here. 
onRefresh(wac); 

} 

if (this.publishContext) { 
// Publish the context as a servlet context attribute. 


String attrName = getServletContextAttributeName(); 


getServletContext().setAttribute(attrName, wac); 
if (this.logger.isDebugEnabled()) 1 
this.logger.debug(" Published WebApplicationContext of servlet 
iE 
getServletName() * 


"as ServletContext attribute with name [" + attrName + "]"); 


} 
return wac; 

} 

对 于 本 函数 中 的 初始 化 主要 包含 几 个 部 分 。 

1. 寻找 或 创建 对 应 的 WebApplicationContext 实 例 

WebApplicationContext 的 寻找 及 创建 包括 以 下 几 个 步 又 。 

(1) 通过 构造 函数 的 注入 进行 初始 化 。 

当 进 入 initWebApplicationContext PK 9L Jr; 188 wt 41] BB 
this.webApplicationContext != null 后 ， 便 可 以 确定 
this.webApplicationContext 是 否 是 通过 构造 函数 来 初始 化 的 。 可 是 有 读 
者 可 能 会 有 疑问 ， 在 initServletBean 函 数 中 明明 是 把 创建 好 的 实例 记录 
在 了 this.webApplicationContext 中 : 

this.webApplicationContext= initWebApplicationContext(); 

何以 判定 这 个 参数 是 通过 构造 函数 初始 化 ， 而 不 是 通过 上 一 次 的 函 
数 返 回 值 初始 化 呢 ? 如 果 存 在 这 个 问题 ， 那 么 就 是 读者 忽略 一 个 问题 
了 : 在 Web 中 包含 SpringWeb 的 核心 逻辑 的 DispatcherServlet 只 可 以 被 
声明 为 一 次 ， 在 Spring 中 已 经 存在 验证 ， 所 以 这 就 确保 了 如 果 
this.webApplicationContext != null， 则 可 以 直接 判定 
this.webApplicationContext 已 经 通过 构造 函数 初始 化 。 

(2) 通过 contextAttribute 进 行 初始 化 。 








通过 在 web.xml 文 件 中 配置 的 servlet 人 参数 contextAttribute 来 查找 
ServletContext 中 对 应 的 属性 ， 默 认为 
WebApplicationContext.class.getName() + "ROOT", EWE 
ContextLoaderListener 加 载 时 会 创建 WebApplicationContext 实 例 ， 并 将 实 
例 以 WebApplicationContext.class.getrName() + ".ROOT"A key 放 入 
ServletContext 中 ， 当 然 读者 可 以 重 写 初始 化 逻辑 使 用 自己 创建 的 
WebApplicationContext， 并 在 servlet 的 配置 中 通过 初始 化 参数 
contextAttribute 指 定 key。 
protected WebApplicationContext findWebApplicationContext() { 
String attrName = getContextAttribute(); 
if (attrName == null) { 
return null; 
} 
WebApplicationContext wac = 


attrName); 


WebApplicationContextUtils.getWebApplicationContext(getServletContext() 
if (wac == null) { 
throw new IllegalStateException("No WebApplicationContext 
found: initializer 
not registered?"); 
} 
return wac; 
} 
(3) 重新 创建 WebApplicationContext 实 例 。 
如 果 通 过 以 上 两 种 方式 并 没有 找到 任何 突破 ， 那 就 没 办 法 了 ， 只 能 
在 这 里 重新 创建 新 的 实例 了 。 


protected WebApplicationContext 
createWebApplicationContext(WebApplicationContext parent) { 
return createWebA pplicationContext(( ApplicationContext) parent); 
j 
protected WebApplicationContext 
createWebApplicationContext(ApplicationContext parent) 1 
/获取 servlet 的 初始 化 参数 contextClass, 如 果 没 有 配置 默认 为 
XmlWebApplicationContext.class 
Class<?> contextClass = getContextClass(); 
if (this. logger.isDebugEnabled()) { 
this.logger.debug("Servlet with name " + getServletName() + 
will try to create custom WebApplicationContext context of 
class ™ + 
contextClass.getName() + "" + ", using parent context [" + parent 
+"); 
} 
if 
(!ConfigurableWebApplicationContext.class.isAssignableFrom(contextClass) 
{ 
throw new ApplicationContextException( 
"Fatal initialization error in servlet with name " + 
getServletName() + 
"': custom WebApplicationContext class [" + 
contextClass.getName() + 
"] is not of type ConfigurableWebApplicationContext"); 
j 
/通过 反射 方式 实例 化 contextClass 


ConfigurableWebApplicationContext wac = 
(ConfigurableWebApplicationContext) BeanUtils.instantiateClass 
(contextClass); 
/parent 为 在 ContextLoaderListener 中 创建 的 实例 
/在 ContextLoaderListener 加 载 的 时 候 初 始 化 的 
WebApplicationContext 类 型 实例 
wac.setParent(parent); 
/获取 contextConfigLocation 必 性， 配置 在 servlet 初 始 化 参数 中 
wac.setConfigLocation(getContextConfigLocation()); 
/初始 化 Spring 环境 包括 加 载 配置 文件 等 
configureAndRefreshWebApplicationContext(wac); 
return wac; 
} 
2. configureAndRefreshWebApplicationContext 
无 论 是 通过 构造 函数 注入 还 是 单独 创建 ， 都 免不了 会 调用 
configureAndRefreshWeb Application Context 方 法 来 对 已 经 创建 的 
WebApplicationContext 实 例 进行 配置 及 刷新 ， 那 么 这 个 步骤 又 做 了 哪些 
TIEI? 
protected void 
configureAndRefreshWebApplicationContext(ConfigurableWebApplication 
Context wac, ServletContext sc) { 
if (ObjectUtils.identity ToString(wac).equals(wac.getId())) { 
// The application context id is still set to its original default value 
// -> assign a more useful id based on available information 
String idParam = sc.getInitParameter(CONTEXT ID PARAM); 
if (idParam != null) { 


wac.setId(idParam); 


} 
else { 
// Generate default id... 
if (sc.getMajorVersion() == 2 && sc.getMinorVersion() < 5) { 


// Servlet <= 2.4: resort to name specified in web.xml, if any. 


wac.setId(ConfigurableWebApplicationContext.APPLICATION_ 
CONTEXT_ 
ID_PREFIX + 
ObjectUtils.getDisplayString(sc.getServletContextName())); 
} 


else { 


wac.setId(ConfigurableWebApplicationContext. APPLICATION CONTEXT. 
ID PREFIX + 
ObjectUtils.getDisplayString(sc.getContextPath())); 


} 


// Determine parent for root web application context, if any. 
ApplicationContext parent = loadParentContext(sc); 
wac.setParent(parent); 
wac.setServletContext(sc); 
String initParameter = 
sc.getInitParameter(CONFIG LOCATION PARAM); 
if (initParameter != null) { 


wac.setConfig Location(initParameter); 


} 
customizeContext(sc, wac); 
/加 载 配置 文件 及 整合 parent 到 wac 
wac.refresh(); 
} 
无 论调 用 方式 如 何 变化 ， 只 要 是 使 用 AlicationContext 所 提供 的 功 
能 最 后 都 免不了 使 用 公共 父 类 AbstractApplicationContext 提 供 的 refresh() 
进行 配置 文件 加 载 。 
3. 刷新 
onRefresh 是 FrameworkServlet 类 中 提供 的 模板 方法 ， 在 其 子 类 
DispatcherServlet 中 进行 了 重 写 ， 主 要 用 于 刷新 Spring 在 Web 功 能 实现 中 
所 必须 使 用 的 全 局 变量 。 下 面 我 们 会 介绍 它们 的 初始 化 过 程 以 及 使 用 场 
景 ， 而 至 于 具体 的 使 用 细节 会 在 稍 后 的 章节 中 再 做 详细 介绍 。 


protected void onRefresh(ApplicationContext context) { 











initStrategies(context); 

} 

protected void initStrategies(ApplicationContext context) { 
//(1) 初 始 化 MultipartResolver 
initMultipartResolver(context); 
//(2) 初 始 化 LocaleResolver 
initLocaleResolver(context); 
//(3) 初 始 化 ThemeResolver 
initThemeResolver(context); 
//(4)#) 4a HandlerMappings 
initHandlerMappings(context); 
//(5) 初 始 化 HandlerAdapters 
initHandlerA dapters(context); 


/(6) 初 始 化 HandlerExceptionResolvers 
initHandlerExceptionResolvers(context); 
I/(7)8] LRM RequestToViewNameTranslator 
initRequestToViewNameTranslator(context); 
//(8) 初 始 化 ViewResolvers 
initViewResolvers(context); 
//(9) 初 始 化 FlashMapManager 
initFlashMapManager(context); 
} 
(1) 初始 化 MultipartResolver。 
在 Spring 中 ，MnultipartResolver 主 要 用 来 处 理 文 件 上 上传。 默认 情况 
下 ，Spring 是 没有 multipart 处 理 的 ， 因 为 一 些 开 发 者 想 要 自己 处 理 它 
们 。 如 果 想 使 用 Spring 的 multipart， 则 需要 在 Web 应 用 的 上 下 文中 添 
加 multipart 解 析 器 。 这 样 ， 每 个 请 求 就 会 被 检查 是 否 包 售 multipart。 然 
而 ， 如 果 请 求 中 包含 multipart， 那 么 上 下 文中 定义 的 MultipartResolver 就 
会 解析 它 ， 这 样 请 求 中 的 multipart 属 性 就 会 象 其 他 属性 一 样 被 处 理 。 常 
用 配置 如 下 : 


<bean id="multipartResolver" 





class="org.Springframework.web.multipart.commons. Commons 

MultipartResolver"> 

<!-- 该 属性 用 来 配置 可 上 传 文件 的 最 大 byte 数 --> 

<property name="maximumFileSize"><value>100000</value> 
</property> 

</bean> 

"A/S, CommonsMultipartResolver 还 提供 了 其 他 功能 用 于 帮助 用 户 
完成 上 传 功能 ， 有 兴趣 的 读者 可 以 进一步 查看 。 

那么 MultipartResolver 就 是 在 initMultipartResolver 中 被 加 入 到 


DispatcherServlet 中 的 。 
private void initMultipartResolver(ApplicationContext context) { 
try { 
this.multipartResolver = 
context.getBean(MULTIPART_RESOLVER_BEAN_NAME, 
MultipartResolver.class); 
if (logger.isDebugEnabled()) { 
logger.debug(" Using MultipartResolver [" + 
this.multipartResolver + "]"); 
j 
j 
catch (NoSuchBeanDefinitionException ex) 1 
// Default is no multipart resolver. 
this.multipartResolver - null; 
if (logger.isDebugEnabled()) { 
logger.debug("Unable to locate MultipartResolver with name ” 


MULTIPART RESOLVER BEAN NAME + 


"no multipart request handling provided"); 


} 
因为 之 前 的 步骤 已 经 完成 了 Spring 中 配置 文件 的 解析 ， 所 以 在 这 里 
只 要 在 配置 文件 注册 过 都 可 以 通过 ApplicationContext 提供 的 getBean 方 
法 来 直接 获取 对 应 bean ， 进 而 初始 化 MultipartResolver 中 的 
multipartResolver 变 量 。 
(2) 初始 化 LocaleResolver。 





在 Spring 的 国际 化 配置 中 一 共有 3 种 使 用 方式 。 

基于 URL 人 参数 的 配置 。 

通过 URL 参 数 来 控制 国际 化 ， 比 如 你 在 页 面 上 加 一 句 <a href="? 
locale=zh_CN"> 简 体 中 文 </a> 来 控制 项 目 中 使 用 的 国际 化 参数 。 而 提供 
这 个 功能 的 就 是 AcceptHeaderLocaleResolver， 默 认 的 参数 名 为 locale， 
注意 大 小 写 。 里 面 放 的 就 是 你 的 提交 参数 ， 比 如 en US. zh CNZ 2S 
的 ， 上 其 体 配置 如 下 ; 


<bean id="localeResolver" 








class="org.Springframework.web.servlet.i18n. AcceptHeader 

LocaleResolver'"/> 

基于 session 的 配置 。 

它 通 过 检验 用 户 会 话 中 预 置 的 属性 来 解析 区 域 。 最 常用 的 是 根据 用 
户 本 次 会 话 过 程 中 的 语言 设 定 决定 语言 种 类 例如， 用 户 登录 时 选择 语 
言 种 类 ， 则 此 次 登录 周期 内 统一 使 用 此 语言 设 定 ) ， 如 有 果 该 会 话 属性 不 
存在 ， 它 会 根据 accept-language HTITP 头 部 确定 默认 区 域 。 


<bean id="localeResolver" 








class="org.Springframework.web.servlet.i18n.SessionLocaleResolver'/> 

基于 Cookie 的 国际 化 配置 。 

CookieLocaleResolver 用 于 通过 浏览 器 的 cookie 设 置 取得 Locale 对 
象 。 这 种 策略 在 应 用 程序 不 支持 会 话 或 者 状态 必须 保存 在 客户 端 时 有 
用 ， 配 置 如 下 : 

<bean id="localeResolver" 
class="org.Springframework.web.servlet.i18n.CookieLocaleResolver"/> 

这 3 种 方式 都 可 以 解决 国际 化 的 问题 ， 但 是 ， 对 于 LocalResolver 
的 使 用 基础 是 在 DispatcherServlet 中 的 初始 化 。 

private void initLocaleResolver(ApplicationContext context) { 


try { 


this.localeResolver = 
context.getBean(LOCALE_RESOLVER_BEAN_NAME, Locale 确 

Ñ Resolver.class); 

if (logger.isDebugEnabled()) { 


logger.debug(" Using LocaleResolver [" + this.localeResolver + 


catch (NoSuchBeanDefinitionException ex) 1 
// We need to use the default. 
this.localeResolver = getDefaultStrategy(context, 
LocaleResolver.class); 
if (logger.isDebugEnabled()) { 
logger.debug("Unable to locate LocaleResolver with name ™ + 
LOCALE RESOLVER, BEAN NAME + 


": using default [" + this.localeResolver + "]"); 


} 

提取 配置 文件 中 设置 的 LocaleResolver 来 初始 化 DispatcherServlet 中 
的 localeResolver 属 性 。 

(3) 初始 化 ThemeResolver。 
在 Web 开 发 中 经 各 会 遇 到 通过 主题 Theme 来 控制 网 页 风格 ， 这 将 进 
步 改善 用 户 体验 。 简 单 地 说 ， 一 个 主题 就 是 一 组 静态 资源 《〈 比 如 样式 

表 和 图 片 ) ， 它 们 可 以 影响 应 用 程序 的 视觉 效果 。Spring 中 的 主题 功能 
和 国际 化 功能 非常 类 似 。 构 成 Spring 主题 功能 主要 包括 如 下 内 容 。 











org.Springframework.ui.context.ThemeSource 是 Spring 中 主题 资源 的 
接口 ，Spring 的 主题 需要 通过 ThemeSource 接 口 来 实现 存放 主题 信息 的 

org.Springframework.ui.context.support.ResourceBundleThemeSource 
是 ThemeSource 接 口 默 认 实 现 类 (也 就 是 通过 ResourceBundle 资 源 的 方式 
定义 主题 ) ， 在 Spring 中 的 配置 如 下 : 


<bean id="themeSource" 





class="org.Springframework.ui.context.support.ResourceBundle 

ThemeSource"> 

<property name="basenamePrefix" value="com.test. "></property> 

</bean> 

默认 状态 下 是 在 类 路 径 根 目录 下 碍 找 相应 的 资源 文件 ， 也 可 以 通过 
basenamePrefix 来 制定 。 这 样 ，DispatcherServlet 就 会 在 com.test 包 下 查找 
资源 文件 。 

主题 解析 器 。 

ThemeSource 定义 了 一 些 主题 资源 ， 那 么 不 同 的 用 户 使 用 什么 主题 
AVR VEE SCE? org.Springframework.web.servlet.ThemeResolver 是 主题 
解析 器 的 接口 ， 主 题解 析 的 工作 便 是 由 它 的 子 类 来 完成 。 

对 于 主题 解析 器 的 子 类 主要 有 3 个 比较 常用 的 实现 。 以 主题 文件 
summer.properties 为 例 。 

n FixedThemeResolver 用 于 选择 一 个 固定 的 主题 。 


<bean id="themeResolver" 





class="org.Springframework.web.servlet.theme.FixedTheme Resolver"> 
<property name="defaultThemeName" value="summer"/> 
</bean> 
以 上 配置 的 作用 是 设置 主题 文件 为 summer.properties， 在 整个 项 目 
内 固定 不 变 。 


o CookieThemeResolver 用 于 实现 用 户 所 选 的 主题 ， 以 cookie 的 形式 
存放 在 客户 端的 机 器 上 ， 配 置 如 下 : 

<bean id="themeResolver" 
class="org.Springframework.web.servlet.theme.CookieThemeResolver"> 

<property name-"defaultThemeName" value="summer"/> 

</bean> 

pSessionThemeResolver 用 于 主题 保存 在 用 户 的 HTTP Session 中 。 

<bean id="themeResolver" 
class="org.Springframework.web.servlet.theme.SessionThemeResolver"> 


<property name="defaultThemeName" value="summer"/> 


</bean> 
以 上 配置 用 于 设置 主题 名 称 ， 并 且 将 该 名 称 保存 在 用 户 的 
HttpSession 中 。 


q AbstractThemeResolver 是 一 个 抽象 类 被 SessionThemeResolver 和 
FixedThemeResolver 继 承 ， 用 户 也 可 以 继承 它 来 自 定义 主题 解析 器 。 

拦截 器 。 

如 果 需 要 根据 用 户 请 求 来 改变 主题 ， 那 么 Spring 提供 了 一 个 已 经 实 
现 的 拦截 器 Theme ChangeInterceptor 拦 截 器 了 ， 配 置 如 下 : 


<bean id="themeChangelInterceptor" 





class="org.Springframework.web.servlet.theme. Theme 
Changelnterceptor"> 
<property name="paramName" value="themeName"></property> 
</bean> 
其 中 设置 用 户 请 求 参 数 名 为 themeName， 即 URL 为 ?themeName= 具 
体 的 主题 名 称 。 此 外 ， 还 需要 在 handlerMapping 中 配置 拦截 器 。 当 然 需 
要 在 HandleMapping 中 添加 拦截 器 。 


<property name="interceptors"> 





<list> 
«ref local="themeChangelInterceptor" /> 
</list> 
</property> 
了 解 了 主题 文件 的 简单 使 用 方式 后 ， 再 来 查看 解析 器 的 初始 化 工 
作 ， 与 其 他 变量 的 初始 化 工作 相同 ， 主 题 文件 解析 器 的 初始 化 工作 并 没 
有 任何 特别 需要 说 明 的 地 方 。 
private void initThemeResolver(ApplicationContext context) { 
try { 
this.themeResolver = 
context.getBean(THEME_RESOLVER_BEAN_NAME, ThemeResolver. 
class); 
if (logger.isDebugEnabled()) { 


logger.debug("Using ThemeResolver [" + this.themeResolver + 


catch (NoSuchBeanDefinitionException ex) 1 
// We need to use the default. 
this.themeResolver = getDefaultStrategy(context, 
ThemeResolver.class); 

if (logger.isDebugEnabled()) { 
logger.debug( 
"Unable to locate ThemeResolver with name " + THEME _ 
RESOLVER, BEAN NAME + "': using default [" + 


this.themeResolver + "]"); 


} 

(4) 初始 化 HandlerMappings。 

当 客 户 端 发 出 Request 时 DispatcherServlet 会 将 Request 提交 给 
HandlerMapping， 然 后 HanlerMapping 根据 Web Application Context 的 配 
置 来 回 传 给 DispatcherServlet 相应 的 Controller。 

在 基于 SpringMVC 的 Web 应 用 程序 中 ， 我 们 可 以 为 
DispatcherServlet 提供 多 个 Handler Mapping 供 其 使 用 。DispatcherServlet 
在 选用 HandlerMapping 的 过 程 中 ， 将 根据 我 们 所 指定 的 一 系列 
HandlerMapping 的 优先 级 进行 排序 ， 然 后 优先 使 用 优先 级 在 前 的 
HandlerMapping。 如 果 当 前 的 HandlerMapping 能 够 返回 可 用 的 Handler， 
DispatcherServlet 则 使 用 当前 返回 的 Handler 进 行 Web 请 求 的 处 理 ， 而 不 
再 继续 询问 其 他 的 HandlerMapping。 人 否则 ，DispatcherServlet 将 继续 按照 
各 个 HandlerMapping 的 优先 级 进行 询问 ， 直 到 获取 一 个 可 用 的 Handler 为 
止 。 初 始 化 配置 如 下 : 

private void initHandlerMappings(ApplicationContext context) { 





this.handlerMappings = null; 
if (this.detectAllHandlerMappings) { 
Map<String, HandlerMapping> matchingBeans = 
BeanFactoryUtils.beansOfTypelIncludingAncestors(context, 
HandlerMapping. class, true, false); 
if (ImatchingBeans.isEmpty()) 1 
this.handlerMappings = new ArrayList<HandlerMapping> 
(matchingBeans. 
values()); 
// We keep HandlerMappings in sorted order. 
OrderComparator.sort(this.handlerMappings); 


} 
else { 
try { 
HandlerMapping hm = 
context.getBean(HANDLER_MAPPING_BEAN_NAME, 
HandlerMapping.class); 
this.handlerMappings = Collections.singletonList(hm); 
} 
catch (NoSuchBeanDefinitionException ex) { 


// Ignore, we'll add a default HandlerMapping later. 


j 
// Ensure we have at least one HandlerMapping, by registering 
// a default HandlerMapping if no other mappings are found. 
if (this.handlerMappings == null) 1 
this.handlerMappings = getDefaultStrategies(context, 
HandlerMapping.class); 
if (logger.isDebugEnabled()) { 
logger.debug("No HandlerMappings found in servlet "+ 
getServletName() 


+ ": using default"); 


} 
默认 情况 下 ，SpringMVC 将 加 载 当 前 系统 中 所 有 实现 了 
HandlerMapping 接 口 的 bean。 如 果 只 期 望 SpringMVC 加 载 指定 的 


handlermapping 时 ， 可 以 修改 web.xml 中 的 DispatcherServlet 的 初始 参数 ， 
将 detectAllHandlerMappings 的 值 设置 为 false: 
<init-param> 
<param-name>detectAllHandlerMappings</param-name> 
<param-value>false</param-value> 

</init-param> 

此 时 ， SpringMVC 将 查找 名 为 “<handlerMapping” 的 bean, ， 并 作为 
当前 系统 中 唯一 的 handlermapping。 如 果 没 有 定义 handlerMapping 的 话 ， 
则 SpringMVC 将 按照 org.Springframework. web.servlet.DispatcherServlet 
所 在 目录 下 的 DispatcherServlet.properties 中 所 定义 的 
org.Springframework.web.servlet.HandlerMapping 的 内 容 来 加 载 默 认 的 
handlerMapping “用户 没有 自 定义 Strategies 的 情况 下 )。 

(5) 初始 化 HandlerAdapters。 

从 名 字 也 能 联想 到 这 是 一 个 典型 的 适配器 模式 的 使 用 ， 在 计算 机 编 
程 中 ， 适 配器 模式 将 一 个 类 的 接口 适 配 成 用 户 所 期 待 的 。 使 用 适配器 ， 
可 以 使 接口 不 兼容 而 无 法 在 一 起 工作 的 类 协同 工作 ， 做 法 是 将 类 目 己 的 
接口 包 庄 在 一 个 已 存在 的 类 中 。 那 么 在 处 理 handler 时 为 什么 会 使 用 适 
配器 模式 呢 ? 回答 这 个 问题 我 们 首先 要 分 析 它 的 初始 化 逻辑 。 

private void initHandlerAdapters(ApplicationContext context) { 

this.handlerAdapters = null; 
if (this.detectAllHandlerAdapters) { 
// Find all HandlerAdapters in the ApplicationContext, including 
ancestor 
contexts. 
Map<String, HandlerAdapter> matchingBeans = 
BeanFactoryUtils.beansOfTypelIncludingAncestors(context, 


HandlerAdapter.class, true, false); 


if (ImatchingBeans.isEmpty()) 1 
this.handlerAdapters = new ArrayList<HandlerAdapter> 
(matchingBeans. 
values()); 
// We keep HandlerAdapters in sorted order. 
OrderComparator.sort(this.handlerA dapters); 


j 
else { 
try 1 
HandlerAdapter ha = 
context.getBean(HANDLER ADAPTER BEAN NAME, 
HandlerAdapter.class); 
this.handlerAdapters = Collections.singletonList(ha); 
j 
catch (NoSuchBeanDefinitionException ex) 1 


// Ignore, we'll add a default HandlerAdapter later. 


j 
// Ensure we have at least some HandlerA dapters, by registering 
// default HandlerAdapters if no other adapters are found. 
if (this.handlerAdapters == null) { 
this.handlerAdapters = getDefaultStrategies(context, 
HandlerAdapter.class); 
if (logger.isDebugEnabled()) { 
logger.debug("No HandlerAdapters found in servlet "+ 
getServletName() 


+ ': using default"); 


} 
同样 在 初始 化 的 过 程 中 涉及 了 一 个 变量 detectAllHandlerAdapters， 
detectAll]HandlerAdapters 作 用 和 detectAllHandlerMappings 类 似 ， 只 不 过 
作用 对 象 为 handlerAdapter。 亦 可 通过 如 下 配置 来 强制 系统 只 加 载 bean 
name 为 “handlerAdapter”handlerAdapter。 
<init-param> 
<param-name>detectAllHandlerAdapters</param-name> 
<param-value>false</param-value> 
</init-param> 
如 果 无 法 找到 对 应 的 bean， 那 么 系统 会 尝试 加 载 默 认 的 适配器 。 
protected <T> List<T> getDefaultStrategies(ApplicationContext 
context, Class<T> 
strategyInterface) { 
String key = strategyInterface.getNamer(); 
String value = defaultStrategies.getProperty(key); 
if (value != null) { 
String[] classNames = 
StringUtils.commaDelimitedListToStringArray(value); 
List<T> strategies = new ArrayList<T>(classNames.length); 
for (String className : classNames) { 
try { 
Class<?> clazz = ClassUtils.forName(className, 
DispatcherServlet. 
class.getClassLoader()); 


Object strategy = createDefaultStrategy(context, clazz); 
strategies.add((T) strategy); 
j 
catch (ClassNotFoundException ex) 1 
throw new BeanlnitializationException( 
"Could not find DispatcherServlet's default strategy 
class [" + className + 
"] for interface [" + key + "]", ex); 
} 
catch (LinkageError err) { 
throw new BeanInitializationEXception( 
"Error loading DispatcherServlet's default strategy 
class [" + className + 
"] for interface [" + key + "]: problem with 


class file or dependent class", err); 


} 

return strategies; 
} 
else { 


return new LinkedList<T>(); 


} 

在 getDefaultStrategies 函数 中 ， Spring 会 尝试 从 defaultStrategies 中 
加 载 对 应 的 HandlerAdapter 的 属性 ， 那 么 defaultStrategies 是 如 何 初始 化 的 
呢 ? 

在 当前 类 DispatcherServlet 中 存在 这 样 一 段 初始 化 代码 块 : 


Static { 
try { 
// DEFAULT_STRATEGIES_PATH = 
"DispatcherServlet.properties"; 
ClassPathResource resource = new 
ClassPathResource(DEFAULT_STRATEGIES_PATH, 
DispatcherServlet.class); 
defaultStrategies = 
PropertiesLoaderUtils.loadProperties(resource); 
} 
catch (IOException ex) { 
throw new IllegalStateException(" Could not load 'Dispatcher 
Servlet. 


properties": " + ex.getMessage()); 


} 

在 系统 加 载 的 时 候 ，defaultStrategies 根 据 当前 路 径 
DispatcherServlet.properties 来 初始 化 本 身 ， 查 看 
DispatcherServlet.properties 中 对 应 于 HandlerAdapter 的 属性 : 

org.Springframework.web.servlet.HandlerAdapter=org.Springframework 


pRequestHandlerAdapter,\ 
org.Springframework.web.servlet.mvc.SimpleControllerHandlerAdapter,\ 
org.Springframework.web.servlet.mvc.annotation.AnnotationMethodHandler: 


由 此 得 知 ， 如 果 程 序 开发 人 员 没 有 在 配置 文件 中 定义 目 己 的 适 配 
需 ， 那 么 Spring 会 默认 加 载 配置 文件 中 的 3 个 适配器 。 


作为 总 控制 器 的 派遣 器 servlet 通 过 处 理 器 映射 得 到 处 理 器 后 ， 会 轮 
询 处 理 器 适配器 模块 ， 查 找 能 够 处 理 当 前 HTTP 请 求 的 处 理 占 适配器 的 
实现 ， 处 理 器 适 配 右 模块 根据 处 理 占 映射 返回 的 处 理 器 类 型 ， 例 如 简单 
的 控制 占 类 型 、 注 解 控 制 器 类 型 或 者 远程 调用 处 理 器 类 型 ， 来 选择 某 一 
个 适当 的 处 理 器 适配器 的 实现 ， 从 而 适 配 当 前 的 HITP 请 求 。 

HTTP 请 求 处 理 器 适配器 CHttpRequestHandlerAdapter) 。 

HTTP 请 求 处 理 器 适配器 仅仅 支持 对 HTTP 请 求 处 理 器 的 适 配 。 它 简 
单 地 将 HITP 请 求 对 象 和 响应 对 象 传递 给 HTTP 请 求 处 理 器 的 实现 ， 它 并 
不 需要 返回 值 。 它 主要 应 用 在 基于 HTTP 的 远程 调用 的 实现 上 。 

简单 控制 器 处 理 器 适配器 CSimpleControllerHandlerAdapter) 。 

这 个 实现 类 将 HTTP 请 求 适 配 到 一 个 控制 器 的 实现 进行 处 理 。 这 里 
控制 器 的 实现 是 一 个 简单 的 控制 器 接口 的 实现 。 简 单 控制 器 处 理 器 适 配 
器 被 设计 成 一 个 框架 类 的 实现 ， 不 需要 被 改写 ， 客 户 化 的 业务 多 辑 通 第 
是 在 控制 器 接口 的 实现 类 中 实现 的 。 

注解 方法 处 理 器 适配器 CAnnotationMethodHandlerAdapter) . 

这 个 类 的 实现 是 基于 注解 的 实现 ， 它 需要 结合 注解 方法 映射 和 注解 
方法 处 理 器 协同 工作 。 它 通过 解析 声明 在 注解 控制 器 的 请 求 映射 信息 来 
解析 相应 的 处 理 器 方法 来 处 理 当 前 的 HTTP 请 求 。 在 处 理 的 过 程 中 ， 它 
通过 反 冉 来 发 现 探 测 处 理 器 方法 的 参数 ， 调 用 处 理 器 方法 ， 并 且 映 射 返 
回 值 到 模型 和 控制 器 对 象 ， 最 后 返回 模型 和 控制 器 对 象 给 作为 主 控制 器 
HYKIE 48 Servlet. 

所 以 我 们 现在 基本 上 可 以 回答 之 前 的 问题 了 ，Spring 中 所 使 用 的 
Handler 并 没有 任何 特殊 的 联系 ， 但 是 为 了 统一 处 理 ，Spring 提 供 了 不 同 
情况 下 的 适配器 。 

(6) 初始 化 HandlerExceptionResolvers。 

基于 HandlerExceptionResolver 接 口 的 异常 处 理 ， 使 用 这 种 方式 只 需 

要 实现 resolveException 方 法 ， 该 方法 返回 一 个 ModelAndView 对 象 ， 在 




















方法 内 部 对 异 第 的 类 型 进行 判断 ， 然 后 莹 试 生成 对 应 的 ModelAndView 
对 象 ， 如 采 该 方法 返回 了 null, Wü Spring 会 继续 寻找 其 他 的 实现 了 
HandlerExceptionResolver 接 口 的 bean。 换 名 话说，Spring 会 搜索 所 有 注 
册 在 其 环境 中 的 实现 了 HandlerExceptionResolver 接 口 的 bean， 逐 个 执 
行 ， 直 到 返回 了 一 个 ModelAndView 对 象 。 
import javax.servlet.http.HttpServletRequest; 
import javax.servlet.http.HttpServletResponse; 
import org.apache.commons.logging.Log; 
import org.apache.commons.logging.LogFactory; 
import org.Springframework.stereotype.Component; 
import org.Springframework.web.servlet. HandlerExceptionResolver; 
import org.Springframework.web.servlet. ModelAndView; 
(Q Component 
public class ExceptionHandler implements HandlerExceptionResolver 
{ 
private static final Log logs = 
LogFactory.getLog(ExceptionHandler.class); 
@Override 
public ModelAndView resolveException(HttpServletRequest 
request, HttpServletResponse 
response, Object obj, 


Exception exception) 


request.setAttribute("exception", exception.toString()); 
request.setAttribute("exceptionStack", exception); 
logs.error(exception.toString(), exception); 


return new ModelAndView("error/exception"); 


} 
这 个 类 必须 声明 到 Spring 中 去 ， 让 Spring 管理 它 ， 在 Spring 的 配置 文 
件 applicationContext.xml 中 增加 以 下 内 容 : 


<bean id="exceptionHandler" 





class="com.test.exception.MyExceptionHandler"/> 
初始 化 代码 如 下 : 
private void initHandlerExceptionResolvers(ApplicationContext 
context) { 
this.handlerExceptionResolvers = null; 
if (this.detectAllHandlerExceptionResolvers) { 
// Find all HandlerExceptionResolvers in the ApplicationContext, 
including 
ancestor contexts. 
Map<String, HandlerExceptionResolver> matchingBeans = 
BeanFactory Utils 
.beansOfTypeIncludingAncestors(context, 
HandlerExceptionResolver. 
class, true, false); 
if (ImatchingBeans.isEmpty()) 1 
this.handlerExceptionResolvers = new ArrayList<Handler 
Exception 
Resolver>(matchingBeans.values()); 
// We keep HandlerExceptionResolvers in sorted order. 


OrderComparator.sort(this.handlerExceptionResolvers); 


else { 


try { 
HandlerExceptionResolver her = 


context.getBean(HANDLER_EXCEPTION_RESOLVER_BEAN_NAME, 
HandlerExceptionResolver.class); 
this.handlerExceptionResolvers = 
Collections.singletonList(her); 
} 
catch (NoSuchBeanDefinitionException ex) { 


// Ignore, no HandlerExceptionResolver is fine too. 


j 

// Ensure we have at least some HandlerExceptionResolvers, by 
registering 

// default HandlerExceptionResolvers if no other resolvers are found. 

if (this.handlerExceptionResolvers == null) { 


this.handlerExceptionResolvers - getDefaultStrategies(context, 


Handler 
ExceptionResolver.class); 
if (logger.isDebugEnabled()) { 
logger.debug("No HandlerExceptionResolvers found in servlet 
"o 
getServletName() + ": using default"); 
j 
j 


(7) 初始 化 RequestToViewNameTranslator。 

当 Controller 处 理 器 方法 没有 返回 一 个 View 对 象 或 逻辑 视图 名 称 ， 
并 且 在 该 方法 中 没有 直接 往 response 的 输出 流 里 面 写 数据 的 时 候 ，Spring 
就 会 采用 约定 好 的 方式 提供 一 个 逻辑 视图 名 称 。 这 个 逻辑 视图 名 称 是 通 
过 Spring 定义 的 org.Springframework.web.servlet.RequestToView 
NameTranslator 接 口 的 getViewName 方 法 来 实现 的 ， 我 们 可 以 实现 自己 
的 Request ToViewName Translator 接 口 来 约定 好 没有 返回 视图 名 称 的 时 
候 如 何 确定 视图 名 称 。Spring 已 经 给 我 们 提供 了 一 个 它 自 己 的 实现 ， 那 
Wiz org.Springframework.web.servlet.view.DefaultRequest 
ToViewName&nbsp; Translator. 

在 介绍 DefaultRequestTo ViewNameTranslator 是 如 何 约定 视图 名 称 
之 前 ， 先 来 看 一 下 它 文 持 用 户 定义 的 属性 。 

prefix: 前 级 ， 表 示 约 定好 的 视图 名 称 需 要 加 上 的 前 级 ， 默 认 是 空 
FF 

suffix: Aa, RNA NAA 4 ie ON ENR, SAY ET 
ta 

separator: |^, SAWCERHLT". 

stripLeadingSlash: 如 果 首 字符 是 分 隔 符 ， 是 否 要 去 除 ， 默 认 是 
true。 

stripTrailingSlash: 如 果 最 后 一 个 字符 是 分 隔 符 ， 是 否 要 去 除 ， 默 认 
是 true。 

stripExtension: 如 果 请 求 路 径 包 含 扩展 名 是 否 要 去 除 ， 默 认 是 
true。 

urlDecode: 是 否 需 要 对 URL 解码 ， 默 认 是 true。 它 会 采用 request 

间 定 的 编码 或 者 ISO-8859-1 编 码 对 URL 进 行 解码 。 

当 我 们 没有 在 SpringMVC 的 配置 文件 中 手动 的 定义 一 个 名 为 

viewNameTranlator 的 Bean 的 时 候 ，Spring 就 会 为 我 们 提供 一 个 默认 的 











viewNameTranslator, |) DefaultRequest ToViewName Translator. 

接 下 来 看 一 下 ， 当 Controller 处 理 咒 方法 没有 返回 逻辑 视图 名 称 
时 ，DefaultRequestToView NameTranslator 是 如 何 约定 视图 名 称 的 。 
DefaultRequestToViewNameTranslator 会 获取 到 请 求 的 URI， 然 后 根据 提 
供 的 属性 做 一 些 改造 ， 把 改造 之 后 的 结果 作为 视图 名 称 返 回 。 这 里 以 请 
求 路 径 http://localhost/app/test/index.html 为 例 ， 来 说 明 一 下 
DefaultRequestToViewNameTranslator 是 如 何 工 作 的 。 该 请 求 路 径 对 应 的 
请 求 URI 为 /test/index.html， 我 们 来 看 以 下 几 种 情况 ， 它 分 别 对 应 的 由 
辑 视 图 名 称 是 什么 。 

prefix 和 suffix 如 果 都 存在 ， 其 他 为 默认 值 ， 那 么 对 应 返回 的 逻辑 
视图 名 称 应 该 是 prefixtest/indexsuffix。 

stripLeadingSlash 和 stripExtension 都 为 false， 其 他 默认 ， 这 时 候 对 应 
的 逻辑 视图 名 称 是 /product/index.html。 

都 采用 默认 配置 时 ， 返 回 的 逻辑 视图 名 称 应 该 是 product/index。 

如 果 逻 辑 视图 名 称 跟 请 求 路 径 相 同 或 者 相关 关系 都 是 一 样 的 ， 那 么 
我 们 就 可 以 采用 Spring 为 我 们 事先 约定 好 的 逻辑 视图 名 称 返 回 ， 这 可 以 
大 大 简化 我 们 的 开发 工作 ， 而 以 上 功能 实现 的 关键 属性 


viewNameTranslator， 则 是 在 initRequestToViewNameTranslator 中 完成 。 





private void initRequestToViewNameTranslator(ApplicationContext 
context) 1 
try 1 
this. viewNameTranslator = 


context.getBean(REQUEST TO VIEW NAME TRANSLATOR BEAN N 
RequestToViewNameTranslator.class); 
if (logger.isDebugEnabled()) { 
logger.debug("Using RequestToViewNameTranslator [" + 


this. viewName 


Translator + "]"); 


j 
catch (NoSuchBeanDefinitionException ex) 1 
// We need to use the default. 
this. viewNameTranslator = getDefaultStrategy(context, 
RequestToViewName 
Translator.class); 
if (logger.isDebugEnabled()) { 
logger.debug("Unable to locate RequestToViewNameTranslator 


with name "+ 


REQUEST TO VIEW NAME TRANSLATOR BEAN NAME + "': using 
default 
[" + this. viewNameTranslator + 


T» 


} 

(8) 初始 化 ViewResolvers。 

在 SpringMVC 中 ， 当 Controller 将 请 求 处 理 结果 放 入 到 
ModelAndView 中 以 后 ， DispatcherServlet 会 根据 ModelAndView 选 择 合 
适 的 视图 进行 渲染 。 那 么 在 SpringMVC 中 是 如 何 选择 合适 的 View 呢 ? 
View 对 象 是 是 如 何 创 建 的 呢 ? 答案 束 在 ViewResolver 中 。ViewResolver 
接口 定义 了 resolverViewName 方 法 ， 根 据 viewName 创 建 合适 类 型 的 
View 实 现 。 


那么 如 何 配置 ViewResolver 呢 ? 在 Spring 中 ，ViewResolver 作 为 
Spring Bean 存 在 ， 可 以 在 Spring 配置 文件 中 进行 配置 ， 例 如 下 面 的 代 
码 ， 配 置 了 JSP 相 关 的 viewResolver。 

<bean 
class="org.Springframework.web.servlet.view.InternalResourceViewResolveil 

<property name="prefix" value="/WEB-INF/views/"/> 
«property name="suffix" value=".jsp"/> 

</bean> 

viewResolvers 属 性 的 初始 化 工作 在 initViewResolvers 中 完成 。 

private void initViewResolvers(ApplicationContext context) { 

this.viewResolvers = null; 
if (this.detectAllViewResolvers) { 
// Find all ViewResolvers in the ApplicationContext, including 
ancestor 
contexts. 
Map<String, ViewResolver> matchingBeans = 
BeanFactoryUtils.beansOfTypelIncludingAncestors(context, 
ViewResolver.class, true, false); 
if (ImatchingBeans.isEmpty()) 1 
this.viewResolvers = new ArrayList<ViewResolver> 
(matchingBeans. 
values()); 
// We keep ViewResolvers in sorted order. 


OrderComparator.sort(this.viewResolvers); 


else { 


try { 
ViewResolver vr = 
context.getBean(VIEW_RESOLVER_BEAN_NAME, ViewResolver. 
class); 
this.viewResolvers = Collections.singletonList(vr); 
} 
catch (NoSuchBeanDefinitionException ex) { 


// Ignore, we'll add a default ViewResolver later. 


} 
// Ensure we have at least one ViewResolver, by registering 
// a default ViewResolver if no other resolvers are found. 
if (this. viewResolvers == null) { 
this. viewResolvers = getDefaultStrategies(context, 
ViewResolver.class); 
if (logger.isDebugEnabled()) { 
logger.debug("No ViewResolvers found in servlet '™ + 
getServletName() 


+ ": using default"); 


} 
(9) 初始 化 FlashMapManager。 
SpringMVC Flash attributes 提 供 了 一 个 请 求 存 储 属 性 ， 可 供 其 他 请 
求 使 用 。 在 使 用 重 定向 时 候 非 常 必要 ， 例 如 Post/Redirect/Get 模 式 。 
Flash attributes 在 重 定 向 之 前 暂 存 (就 像 存 在 session 中 ) 以便 重 定向 之 
后 还 能 使 用 ， 并 立即 删除 。 





SpringMVC 有 两 个 主要 的 抽象 来 文 持 flash attributes。FlashMap 用 于 
保持 flash attributes, m FlashMapManager 用 于 存储 、 检 索 、 管 理 
FlashMap 实 例 。 

flash attribute L FRANA Con") 并 不 需要 显 式 启 用 ， 它 永远 不 
会 导致 HTTP Session 的 创建 。 这 两 个 FlashMap 实 例 都 可 以 通过 静态 方法 
RequestContextUtils/\ Spring MVC 的 任何 位 置 访问 。 

flashMapManager 的 初始 化 在 initFlashMapManager 中 完成 。 

private void initFlashMapManager(ApplicationContext context) { 

try { 
this.flashMapManager = 
context.getBean(FLASH_MAP_MANAGER_BEAN_NAME, 
FlashMapManager.class); 
if (logger.isDebugEnabled()) { 
logger.debug("Using FlashMapManager [" + 
this.flashMapManager + "]"); 
} 
} 
catch (NoSuchBeanDefinitionException ex) { 
// We need to use the default. 
this. flashMapManager = getDefaultStrategy(context, 
FlashMapManager. 
class); 
if (logger.isDebugEnabled()) { 
logger.debug("Unable to locate FlashMapManager with name ” 
FLASH MAP MANAGER BEAN NAME + "': using default 


[" 十 


this.flashMapManager + "]"); 


} 


11.4 DispatcherServlet [E] iZ #3 Ath FE 


根据 之 前 的 示例 ， 我 们 知道 在 HttpServlet 类 中 分 别提 供 了 相应 的 服 
务 方法 ， 它 们 是 doDelete()、doGet()、doOptions()、doPost()、doPut() 和 
doTrace0， 它 会 根据 请 求 的 不 同形 式 将 程序 引导 至 对 应 的 函数 进行 处 
理 。 这 几 个 函数 中 最 常用 的 函数 无 非 束 是 doGetQ 和 doPost()， 那 么 我 们 
就 直接 查看 DispatcherServlet 中 对 于 这 两 个 函数 的 逻辑 实现 。 
@Override 
protected final void doGet(HttpServletRequest request, 
HttpServletResponse response) 
throws ServletException, IOException { 
processRequest(request, response); 
@Override 
protected final void doPost(HttpServletRequest request, 
HttpServletResponse response) 
throws ServletException, IOException { 
processRequest(request, response); 
} 
对 于 不 同 的 方法 ，Spring 并 没有 做 特殊 处 理 ， 而 是 统一 将 程序 再 一 
次 地 引导 至 process Request(request, response) 中 。 


protected final void processRequest(HttpServletRequest request, 


HttpServletResponse 
response) 
throws ServletException, IOException { 
/记录 当前 时 间 ， 用 于 计算 web 请 求 的 处 理 时 间 
long startTime = System.currentTimeMillis(); 
Throwable failureCause = null; 
// Expose current LocaleResolver and request as LocaleContext. 
LocaleContext previousLocaleContext = 
LocaleContextHolder.getLocaleContext(); 
LocaleContextHolder.setLocaleContext(buildLocaleContext(request), 
this.threadContextInheritable); 
// Expose current RequestAttributes to current thread. 
RequestAttributes previousRequestAttributes = 
RequestContextHolder. GetRequest 
Attributes(); 
ServletRequestAttributes requestAttributes = null; 
if (previousRequestAttributes == null || previousRequestAttributes. 
getClass(). 
equals(ServletRequestAttributes.class)) { 
requestAttributes = new ServletRequestAttributes(request); 
RequestContextHolder.setRequestAttributes(requestAttributes, 
this.threadContextInheritable); 
} 
if (logger.isTraceEnabled()) { 
logger.trace(""Bound request context to thread: " + request); 
} 
try { 


doService(request, response); 
} 
catch (ServletException ex) { 
failureCause = ex; 
throw ex; 
} 
catch (IOException ex) { 
failureCause = ex; 
throw ex; 
} 
catch (Throwable ex) { 
failureCause = ex; 
throw new NestedServletException(" Request processing failed", 
ex); 
j 
finally 1 


// Clear request attributes and reset thread-bound context. 


LocaleContextHolder.setLocaleContext(previousLocaleContext,this.threadCo 
Inheritable); 
if (requestAttributes != null) 1 


RequestContextHolder.setRequestAttributes(previousRequestA ttributes, 
this.threadContextInheritable); 
requestAttributes.requestCompleted(); 


} 
if (logger.isTraceEnabled()) { 


logger.trace("Cleared thread-bound request context: " + 
request); 
} 
if (logger.isDebugEnabled()) 1 
if (failureCause != null) 1 
this.logger.debug("Could not complete request", 
failureCause); 
j 
else { 


this.logger.debug( Successfully completed request"); 


j 

if (this.publishEvents) ( 
// Whether or not we succeeded, publish an event. 
long processingTime = System.currentTimeMillis() - startTime; 
this.webApplicationContext.publishEvent( 
new ServletRequestHandledEvent(this, 
request.getRequestURI(), request.getRemoteA ddr(), 
request.getMethod(), 
getServletConfig().getServletName(), 
WebUtils.getSessionId(request), 
getUsernameForRequest(request), 


processingTime, failureCause)); 


} 
PH AIT oR SMA bE, Se RAEN EHE SI f doService 


函数 中 实现 ， 但 是 我 们 不 难看 出 处 理 请 求 前 后 所 做 的 准备 与 处 理工 作 。 

(1) 为 了 保证 当前 线程 的 LocaleContext 以 及 RequestAttributes 可 以 
在 当前 请 求 后 还 能 恢复 ， 提 取 当 前 线程 的 两 个 属性 。 

(2) 根据 当前 request 创 建 对 应 的 LocaleContext 和 
RequestAttributes， 并 绑 定 到 当前 线程 。 

(3) 委托 给 doService 方 法 进一步 处 理 。 

(4) 请 求 处 理 结束 后 恢复 线程 到 原始 状态 。 

(5) 请 求 处 理 结束 后 无 论 成 功 与 否 发 布 事件 通知 。 

继续 查看 doService 方 法 。 


protected void doService(HttpServletRequest request, 








HttpServletResponse response) throws 
Exception { 
if (logger.isDebugEnabled()) { 
String requestUri = urlPathHelper.getRequestUri(request); 
logger.debug("DispatcherServlet with name "+ getServletName() 
qom 
processing " + request.getMethod() + 
" request for [" + requestUri + "]"); 
} 
// Keep a snapshot of the request attributes in case of an include, 
// to be able to restore the original attributes after the include. 
Map<String, Object> attributesSnapshot = null; 
if (WebUtils.isIncludeRequest(request)) { 
logger.debug(" Taking snapshot of request attributes before 
include"); 
attributesSnapshot = new HashMap<String, Object? (); 


Enumeration<?> attrNames = request.getAttributeNames(); 


while (attrNames.hasMoreElements()) { 

String attrName = (String) attrNames.nextElement(); 

if (this.cleanupAfterInclude || attrName.startsWith 
("org.Springframework. 

web.servlet")) 1 

attributesSnapshot.put(attrName, request.getAttribute 

(attrName)); 

j 


} 


// Make framework objects available to handlers and view objects. 


request.setAttribute(WEB APPLICATION CONTEXT ATTRIBUTE, 
getWebApplicationContext()); 
request.setAttribute(LOCALE RESOLVER, ATTRIBUTE, 
this.localeResolver); 
request.setAttribute(TCHEME RESOLVER, ATTRIBUTE, 
this.themeResolver); 
request.setAttribute(TCHEME SOURCE ATTRIBUTE, 
getThemeSource()); 
FlashMap inputFlashMap = 
this.flashMapManager.retrieve AndUpdate(request, 
response); 
if (inputFlashMap !- null) { 
request.setAttribute(INPUT FLASH MAP ATTRIBUTE, 
Collections.unmodifiableMap 
(inputFlashMap)); 


} 
request.setAttribute(OUTPUT FLASH MAP ATTRIBUTE, new 
FlashMap()); 
request.setAttribute(FLLASH MAP MANAGER ATTRIBUTE, 
this.flashMapManager); 
try 1 
doDispatch(request, response); 
j 
finally { 
// Restore the original attribute snapshot, in case of an include. 
if (attributesSnapshot != null) { 


restoreAttributesA fterInclude(request, attributesSnapshot); 


} 

我 们 猜想 对 请 求 处 理 至 少 应 该 包括 一 些 诸如 寻找 Handler 并 页 面 跳 
转 之 类 的 逻辑 处 理 ， 但 是 ， 在 doService 中 我 们 并 没有 看 到 想 看 到 的 好 
辑 ， 相 反 却 同样 是 一 些 准 备 工 作 ， 但 是 这 些 准 备 工 作 却 是 必 不 可 少 的。 
Spring 将 已 经 初始 化 的 功能 辅助 工具 变量 ， 比 如 localeResolver、 
themeResolver 等 设置 在 request 属 性 中 ， 而 这 些 属性 会 在 接 下 来 的 处 理 中 
yk ERE. 

经 过 层 层 的 准备 工作 ， 终 于 在 doDispatch 消 数 中 看 到 了 完整 的 请 求 
处 理 过 程 。 

protected void doDispatch(HttpServletRequest request, 





HttpServletResponse response) 
throws Exception { 


HttpServletRequest processedRequest = request; 


HandlerExecutionChain mappedHandler = null; 
int interceptorIndex = -1; 
try { 
ModelAndView mv; 
boolean errorView = false; 
try { 
// 如 果 是 MultipartContent 类 型 的 request 则 转换 request 为 
MultipartHttpServletRequest 类 型 的 
request 
processedRequest = checkMultipart(request); 
/根据 request 信 息 寻 找 对 应 的 Handler 
mappedHandler = getHandler(processedRequest, false); 





if (mappedHandler == null || mappedHandler.getHandler() == null) 


/如 果 没 有 找到 对 应 的 handler 则 通过 response 反 馈 错 误 信 息 
noHandlerFound(processedRequest, response); 
return; 
} 
/根据 当前 的 handler 寻 找 对 应 的 HandlerAdapter 
HandlerAdapter ha = 
getHandlerAdapter(mappedHandler. getHandler()); 
// 如 果 当 前 handler 支 持 last-modified 汰 处理 
String method = request.getMethod(); 
boolean isGet = "GET".equals(method); 
if (isGet || "HEAD". .equals(method)) { 
long lastModified = ha.getLastModified(request, 
mappedHandler. 


getHandler()); 

if (logger.isDebugEnabled()) { 
String requestUri = urlPathHelper.getRequestUri(request); 
logger.debug("Last-Modified value for [" + requestUri + "] is: 
"+ JastModified); 

j 

if (new ServletWebRequest(request, 

response).checkNotModified 
(lastModified) && isGet) 1 


return; 


/拦截 器 的 preHandler 方 法 的 调用 
HandlerInterceptor[] interceptors = 
mappedHandler.getInterceptors(); 
if (interceptors != null) { 
for (int i = 0; i < interceptors.length; i++) { 
HandlerInterceptor interceptor = interceptors[i]; 
if (!interceptor.preHandle(processedRequest, response, 
mappedHandler.getHandler())) { 
triggerA fterCompletion(mappedHandler, 
interceptorIndex, 
processedRequest, response, null); 
return; 
} 


interceptorIndex = i; 


} 
/真正 的 激活 handler 并 返回 视图 
mv = ha.handle(processedRequest, response, 
mappedHandler.getHandler()); 
// 视 图 名 称 转换 应 用 于 需要 添加 前 级 后 级 的 情况 
if (mv != null && !mv.hasView()) { 
mv.setViewName(getDefaultViewName(request)); 
j 
// 应 用 所 有 拦截 器 的 postHandle 方 法 
if (interceptors != null) { 
for (int i = interceptors.length - 1; i >= 0; i--) { 
HandlerInterceptor interceptor = interceptors[i]; 
interceptor.postHandle(processedRequest, response, 
mappedHandler. 
getHandler(), mv); 
} 


} 
catch (ModelAndViewDefiningException ex) { 
logger.debug("ModelAndViewDefiningException encountered", 
ex); 
mv = ex.getModelAndView(); 
} 
catch (Exception ex) { 
Object handler = (mappedHandler != null ? 
mappedHandler.getHandler() : null); 


mv -processHandlerException(processedRequest, response, 


handler, ex); 
errorView = (mv != null); 
} 
// Did the handler return a view to render? 
// 如 果 在 Handler 实 例 的 处 理 中 返回 了 view， 那 么 需要 做 页 面 的 
处 理 
if (mv != null && !mv.wasCleared()) 1 
/处 理 页 面 跳 转 
render(mv, processedRequest, response); 
if (errorView) { 


WebUtils.clearErrorRequestAttributes(request); 


} 
else { 
if (logger.isDebugEnabled()) { 
logger.debug("Null ModelAndView returned to 
DispatcherServlet 
with name "' + getServletName() + 


™: assuming HandlerAdapter completed request handling"); 


} 
/完成 处 理 激活 触发 器 
triggerAfterCompletion(mappedHandler, interceptorIndex, 
processedRequest, 
response, null); 
j 


catch (Exception ex) 1 


// Trigger after-completion for thrown exception. 
triggerAfterCompletion(mappedHandler, interceptorIndex, 
processedRequest, 
response, ex); 
throw ex; 
j 
catch (Error err) 1 
ServletException ex = new NestedServletException(" Handler 
processing 
failed", err); 
// Trigger after-completion for thrown exception. 
triggerAfterCompletion(mappedHandler, interceptorIndex, 
processedRequest, 
response, ex); 
throw ex; 
j 
finally 1 
// Clean up any resources used by a multipart request. 
if (processedRequest != request) { 


cleanupMultipart(processedRequest); 


} 

doDispatch 函数 中 展示 了 Spring ARTE ATI AY EB H, mR 
们 之 前 设置 在 request 中 的 各 种 辅助 属性 也 都 有 被 派 上 了 用 场 。 下 面 回顾 
一 下 逻辑 处 理 的 全 过 程 。 





11.4.1 MultipartContent 类 型 的 request 处 理 


对 于 请 求 的 处 理 ，Spring 首 先 考虑 的 是 对 于 Multipart 的 处 理 ， 如 采 
是 MultipartContent 类 型 的 request， 则 转换 request 为 
MultipartHttpServletRequest 类 型 的 request。 
protected HttpServletRequest checkMultipart(HttpServletRequest 
request) throws 
MultipartException { 
if (this.multipartResolver != null && 
this.multipartResolver.isMultipart(request)) { 
if (request instanceof MultipartHttpServletRequest) { 
logger.debug(" Request is already a MultipartHttpServletRequest 
- if not 
in a forward, " + 
"this typically results from an additional MultipartFilter in 
web.xml"); 
j 
else { 


return this.multipartResolver.resolveMultipart(request); 


} 


// If not returned before: return original request. 


return request; 





££ Spring HP 3t fia] FL AR SBS Ach EE SR CSU P : 
<bean id="simpleUrlMapping" 


"T 


class-"org.Springframework.web.servlet.handler.SimpleUrlHandlerMapping 
<property name="mappings"> 
<props> 
<prop key="/userlist.htm">userController</prop> 
</props> 
</property> 
</bean> 
在 Spring 加 载 的 过 程 中 ，Spring 会 将 类 型 为 
SimpleUrlHandlerMapping 的 实例 加 载 到 this.handlerMappings 中 ， 按 照常 
理 推 朵 ， 根 据 request 提 取 对 应 的 Handler， 无 非 就 是 提取 当前 实例 中 的 
userController， 但 是 userController 为 继承 自 AbstractController 类 型 实例 ， 
与 Handler ExecutionChain 并 无 任何 关联 ， 那 么 这 一 步 是 如 何 封装 的 呢 ? 
protected HandlerExecutionChain getHandler(HttpServletRequest 





request, boolean cache) 
throws Exception { 
return getHandler(request); 
} 
protected HandlerExecutionChain getHandler(HttpServletRequest 
request) throws Exception { 
for (HandlerMapping hm : this.handlerMappings) { 
if (logger.isTraceEnabled()) { 
logger.trace( 
"Testing handler map [" + hm + "] in DispatcherServlet with 
name " + getServletName() + """); 


j 
HandlerExecutionChain handler = hm.getHandler(request); 


if (handler != null) { 


return handler; 


} 


return null; 


} 
在 之 前 的 内 容 我 们 提 过 ， 在 系统 启动 时 Spring 会 将 所 有 的 映射 类 型 
的 bean 注册 到 this.handlerMappings 变量 中 ， 所 以 此 函数 的 目的 束 是 通 
历 所 有 的 HandlerMapping， 并 调用 其 getHandler 方 法 进行 封装 处 理 。 以 
SimpleUrlHandlerMapping 为 例 查 看 其 getHandler 方 法 如 下 : 
public final HandlerExecutionChain getHandler(HttpServletRequest 
request) throws 
Exception { 
// 根 据 request 获 取 对 应 的 handler 
Object handler = getHandlerInternal(request); 
if (handler == null) { 
// 如 果 没 有 对 应 request 的 handler 则 使 用 默认 的 handler 
handler = getDefaultHandler(); 
} 
/如 果 也 没有 提供 默认 的 handler 则 无 法 继续 处 理 返回 null 
if (handler == null) { 
return null; 
} 
// Bean name or resolved handler? 
if (handler instanceof String) { 
String handlerName = (String) handler; 
handler = getApplicationContext().getBean(handlerName); 


} 


return getHandlerExecutionChain(handler, request); 


函数 中 首先 会 使 用 getHandlerInternal 方法 根据 request 信息 获取 对 
应 的 Handler， 如 果 以 SimpleUrlHandlerMapping 为 例 分 析 ， 那 么 我 们 推 
斯 此 步骤 提供 的 功能 很 可 能 束 是 根据 URL 找 到 匹配 的 Controller 并 返回 ， 
当然 如 果 没 有 找到 对 应 的 Controller 处 理 器 那么 程序 会 尝试 去 查找 配置 
中 的 默认 处 理 器 ， 当 然 ， 当 查找 的 controller 为 String 类 型 时 ， 那 就 意味 
着 返回 的 是 配置 的 bean 名 称 ， 需 要 根据 bean 名 称 查 找 对 应 的 bean， 最 
后 ， 还 要 通过 getHandlerExecutionChain 方 法 对 返回 的 Handler 进 行 封 装 ， 
以 保证 满足 返回 类 型 的 匹配 。 下 面 详细 分 析 这 个 过 程 。 

1. 根据 request 人 查找 对 应 的 Handler 

首先 从 根据 request 得 找 对 应 的 Handler 开 始 分 析 。 


protected Object getHandlerInternal(HttpServletRequest request) throws 











Exception { 
/截取 用 于 匹配 的 um 有效 路 径 
String lookupPath = 
getUrlPathHelper().getLookupPathForRequest(request); 
/根据 路 径 寻 找 Handler 
Object handler = lookupHandler(lookupPath, request); 
if (handler == null) { 
Object rawHandler = null; 
if ("/".equals(lookupPath)) { 
HOR RA ER TEI Me)”, HS fii RootHandleri# fT Ab 
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rawHandler = getRootHandler(); 


if (rawHandler == null) { 
/无 法 找到 handler 则 使 用 默认 handler 
rawHandler = getDefaultHandler(); 
} 
if (rawHandler != null) { 
/根据 beanName 获 取 对 应 的 bean 
让 (rawHandler instanceof String) { 
String handlerName = (String) rawHandler; 
rawHandler = 
getApplicationContext().getBean(handlerName); 
} 
/模版 方法 
validateHandler(rawHandler, request); 
handler = buildPathExposingHandler(rawHandler, 
lookupPath, lookupPath, null); 
} 
} 
if (handler != null && logger.isDebugEnabled()) { 
logger.debug(" Mapping [" + lookupPath + "| to " + handler); 
} 
else if (handler == null && logger.isTraceEnabled()) { 
logger.trace("No handler mapping found for [" + lookupPath + 


return handler; 


} 
protected Object lookupHandler(String urlPath, HttpServletRequest 


request) throws Exception { 
/直接 匹配 情况 的 处 理 
Object handler = this.handlerMap.get(urlPath); 
if (handler != null) { 
// Bean name 
if (handler instanceof String) { 
String handlerName = (String) handler; 
handler = getApplicationContext().getBean(handlerName); 
j 
validateHandler(handler, request); 
return buildPathExposingHandler(handler, urlPath, url Path, 
null); 
j 
/ 通配符 匹配 的 处 理 
List<String> matchingPatterns = new ArrayList<String>(); 
for (String registeredPattern : this.handlerMap.keySet()) { 
if (getPathMatcher().match(registeredPattern, urlPath)) { 


matchingPatterns.add(registeredPattern); 


} 
String bestPatternMatch = null; 
Comparator<String> patternComparator = 
getPathMatcher().getPatternComparator(urlPath); 
if (!matchingPatterns.isEmpty()) 1 
Collections.sort(matchingPatterns, patternComparator); 
if (logger.isDebugEnabled()) { 
logger.debug(" Matching patterns for request [" + urlPath + "| 


are " + 
matchingPatterns); 
j 
bestPatternMatch = matchingPatterns.get(0); 
j 
if (bestPatternMatch !- null) { 
handler = this.handlerMap.get(bestPatternMatch); 
// Bean name or resolved handler? 
if (handler instanceof String) { 
String handlerName = (String) handler; 
handler = getApplicationContext().getBean(handlerName); 
j 
validateHandler(handler, request); 
String pathWithinMapping = 
getPathMatcher().extractPathWithinPattern 
(bestPatternMatch, urlPath); 
// There might be multiple 'best patterns', let's make sure we 
have the correct 
URI template variables 
// for all of them 
Map<String, String» uriTemplateVariables = new 
LinkedHashMap<String, 
String>(); 
for (String matchingPattern : matchingPatterns) { 
if (patternComparator.compare(bestPatternMatch, 
matchingPattern) == 0) { 


uriTemplate Variables 


.putAll(getPathMatcher().extractUriTemplateVariables 
(matchingPattern, urlPath)); 


} 
if (logger.isDebugEnabled()) { 
logger.debug("URI Template variables for request [" + urlPath + 
"] are 
" + uriTemplateVariables); 
} 
returnbuildPathExposingHandler(handler, bestPatternMatch, 
pathWithinMapping, 
uriTemplate Variables); 
} 
// No handler found... 
return null; 
} 
根据 URL 获 取 对 应 Handler 的 匹配 规则 代码 实现 起 来 虽然 很 长 ， 但 
是 并 不 难 理解 ， 考 虑 了 直接 匹配 与 通配符 两 种 情况 。 其 中 要 提 及 的 是 
buildPathExposingHandler 孙 数 ， 它 将 Handler 封 装 成 了 
HandlerExecutionChain2é 7i? 。 


protected Object buildPathExposingHandler(Object rawHandler, String 








bestMatchingPattern, 
String pathWithinMapping, Map<String, String> uriTemplate Variables) 


HandlerExecutionChain chain = new 
HandlerExecutionChain(rawHandler); 


chain.addInterceptor(new 


PathExposingHandlerInterceptor(bestMatchingPattern， 
pathWithinMapping)); 
if (!CollectionUtils.isEmpty(uriTemplateVariables)) { 
chain.addInterceptor(new 
UriTemplate VariablesHandlerInterceptor (uri 
TemplateVariables)); 
} 
return chain; 

} 

在 函数 中 我 们 看 到 了 通过 将 Handler 以 参数 形式 传 入 ， 并 构建 
HandlerExecutionChain 类 型 实例 ， 加 入 了 两 个 拦截 器 。 此 时 我 们 似乎 已 
经 了 解 了 Spring 这 样 大 番 周 折 的 目的 。 链 处 理 机 制 ， 是 Spring 中 非常 常 
用 的 处 理 方 式 ， 是 AOP 中 的 重要 组 成 部 分 ， 可 以 方便 地 对 目标 对 象 进行 
扩展 及 拦截 ， 这 是 非常 优秀 的 设计 。 

2. 加 入 拦截 器 到 执行 链 

getHandlerExecutionChain 疯 数 最 主要 的 目的 是 将 配置 中 的 对 应 拦截 
器 加 入 到 执行 链 中 ， 以 保证 这 些 拉 截 器 可 以 有 效 地 作用 于 目标 对 象 。 

protected HandlerExecutionChain getHandlerExecutionChain(Object 














handler, HttpServletRequest 
request) { 
HandlerExecutionChain chain = 
(handler instanceof HandlerExecutionChain) ? 
(HandlerExecutionChain) handler : new 
HandlerExecutionChain(handler); 
chain.addInterceptors(getAdaptedInterceptors()); 
String lookupPath = 
urlPathHelper.getLookupPathForRequest(request); 


for (MappedInterceptor mappedInterceptor : mappedInterceptors) { 
if (mappedInterceptor.matches(lookupPath, pathMatcher)) { 


chain.addInterceptor(mappedInterceptor.getInterceptor()); 


return chain; 


j 
11.4.3 没 找到 对 应 的 Handler 的 错误 处 
每 个 请 求 都 应 该 对 应 着 一 Handler， 因 为 每 个 请 求 都 会 在 后 台 有 相 
应 的 逻辑 对 应 ， 而 逻辑 的 实现 就 是 在 Handler 中 ， 所 以 一 旦 过 到 没有 找 
到 Handler 的 情况 正常 情况 下 如 果 没 有 URL 区 配 的 Handler， 开 发 人 员 
可 以 设置 默认 的 Handler 来 处 理 请 求 ， 但 是 如 果 默 认 请 求 也 未 设置 就 会 
出 现 Handler 为 空 的 情况 ) ， 就 只 能 通过 response 回 用 户 返 回 错误 信息 。 
protected void noHandlerFound(HttpServletRequest request, 
HttpServletResponse response) 
throws Exception { 
if (pageNotFoundLogger.isWarnEnabled()) 1 
String requestUri = urlPathHelper.getRequestUri(request); 
pageNotFoundLogger.warn("No mapping found for HTTP request 


with URI [" + 
requestUri + 
"] in DispatcherServlet with name "+ getServletName() + """); 


j 
response.sendError(HttpServletResponse.SC NOT FOUND); 


11.4.4 当前 Handler 寻 找 对 应 的 HandlerAdapter 


在 WebApplicationContext 的 初始 化 过 程 中 我 们 讨论 了 
HandlerAdapters 的 初始 化 ， 了 解 了 在 默认 情况 下 普通 的 Web 请 求 会 交 
给 SimpleControllerHandlerAdapter 去 处 理 。 下 面 我 们 以 
SimpleControllerHandlerAdapter 为 例 来 分 析 获 取 适 配器 的 逻辑 。 

protected HandlerAdapter getHandlerAdapter(Object handler) throws 
ServletException { 

for (HandlerAdapter ha : this.handlerAdapters) { 
if (logger.isTraceEnabled()) { 
logger.trace(""Testing handler adapter [" + ha + "]"); 
} 
if (ha.supports(handler)) { 


return ha; 


} 
throw new ServletException("No adapter for handler [" + handler + 
"|: Does your handler implement a supported interface like 
Controller?"); 
} 
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前 的 Handler 逻 辑 被 封装 在 具体 的 适配器 中 。 进 一 步 查 看 
SimpleControllerHandlerAdapter 中 的 supports 方 法 。 
public boolean supports(Object handler) { 
return (handler instanceof Controller); 
} 
分 析 到 这 里 ， 一 切 已 经 明了 ，SimpleControllerHandlerAdapter 就 是 
用 于 处 理 普通 的 Web 请 求 的 ， 而 且 对 于 SpringMVC 来 说 ， 我 们 会 把 逻辑 


封装 至 Controller 的 子 类 中 ， 例 如 我 们 之 前 的 引导 示例 UserController i 
是 继承 自 AbstractController ， 而 AbstractController 实现 Controller 接 口 。 


11.4.5 缓存 处 性 


在 研究 Spring 对 绥 存 处 理 的 功能 文 持 前 ， 我 们 先 了 解 一 个 概念 : 
Last-Modified 缓 存 机 制 | 。 
(1) 在 客户 端 第 一 次 输入 URL 时 ， 服 务 器 端 会 返回 内 容 和 状态 码 
200， 表 示 请 求 成 功 ， 同 
时 会 添加 一 个 “Last-Modified” 的 响应 头 ， 表 示 此 文件 在 服务 器 上 的 
最 后 更 新 时 间 ， 例 如 ，“Last-Modified:Wed, 14 Mar 2012 10:22:42 
GMT” 表 示 最 后 更 新 时 间 为 (2012-03-14 10:22) 。 
(2) 客户 端 第 二 次 请 求 此 URL 时 ， 客 户 端 会 向 服务 器 发 送 请 求 
头 “If-Modified-Since”， 询 问 服务 喜 该 时 间 之 后 当前 请 求 内 容 是 否 有 被 修 
改过 ， 如 “If-Modified-Since: Wed, 14 Mar 2012 10:22:42 GMT”， 如 果 服 
务 器 端的 内 容 没 有 变化 ， 则 自动 返回 HTTP 304 状 态 码 〈 只 要 响应 头 ， 
ARKIT, IEMA TE) o 
Spring 提供 的 对 Last-Modified 机 制 的 文 持 ， 只 需要 实现 LastModified 
接口 ， 如 下 所 示 : 
public class HelloWorldLastModifiedCacheController extends 





AbstractController implements 
LastModified { 
private long lastModified; 
protected ModelAndView handleRequestInternal(HttpServletRequest 
req, Http 
ServletResponse resp) throws Exception 1 
/点 击 后 再 次 请 求 当 前 页 面 


resp.getWriter().write("<a href=">this</a>"); 


return null; 
} 
public long getLastModified(HttpServletRequest request) { 
if(lastModified == OL) { 
// 第 一 次 或 者 逻辑 有 变化 的 时 候 ， 应 该 重新 返回 内 容 最 新 修 
改 的 时 间 惟 
lastModified = System.currentTimeMillis(); 
j 


return lastModified; 


j 
HelloWorldLastModifiedCacheController 只 需要 实现 LastModified 接 


口 的 getLastModified 方 法 ， 保 证 当 内 容 发 生 改 变 时 返回 最 新 的 修改 时 间 
BU nf, 

Spring 判断 是 否 过 期 ， 通 过 判断 请 求 的 “If-Modified-Since” 是 否 大 于 
等 于 当前 的 getLast&nbsp;Modified 方 法 的 时 间 戳 ， 如 果 是 ， 则 认为 没有 
修改 。 上 面 的 controller 与 普通 的 controller 并 无 太 大 差别 ， 声 明 如 下 : 

<bean name="/helloLastModified" 


class-"com.test.controller.HelloWorldLastModifiedCache&nbsp;Controller"/: 
11.4.6 HandlerInterceptor[*] 4h 


Servlet API 定 义 的 servlet 过 滤器 可 以 在 ee 的 
前 后 分 别 对 它 进行 前 置 处 理 和 后 置 处 理 。 此 外 ， 有 些 时 候 ， 你 可 能 只 想 
处 理由 某 些 SpringMVC 人 处 理 程 序 处 理 的 Web 请 求 ， 并 在 这 eee iR 
回 的 模型 属性 被 传递 到 视图 之 前 ， 对 它们 进行 一 些 操作 。 

SpringMVC 人 允许 你 通过 处 理 拦截 Web 请 求 ， 进 行 前 置 处 理 和 后 置 
处 理 。 处 理 拦 截 是 在 Spring 的 Web 应 用 程序 上 下 文中 配置 的 ， 因 此 它们 











可 以 利用 各 种 容器 特性 ， 并 引用 容器 中 声明 的 任何 bean。 处 理 拦截 是 针 
对 特殊 的 处 理 程序 映射 进行 注册 的 ， 因 此 和 它 只 拦截 通过 这 些 处 理 程序 映 
射 的 请 求 。 每 个 处 理 拦 截 都 必须 实现 HandlerInterceptor 接 口 ， 它 包含 三 
个 需要 你 实现 的 回调 方法 : preHandle()、postHandle() 和 
afterCompletion()。 第 一 个 和 第 二 个 方法 分 别 是 在 处 理 程序 处 理 请 求 之 
前 和 之 后 被 调用 的 。 第 二 个 方法 还 允许 访问 返回 的 ModelAndView 对 
象 ， 因 此 可 以 在 它 里 面 操 作 模 型 属性 。 最 后 一 个 方法 是 在 所 有 请 求 处 理 
完成 之 后 被 调用 的 (如 视图 呈现 之 后 )， 以 下 是 HandlerInterceptor 的 简 
单 实现 ; 


public class MyTestInterceptor implements HandlerInterceptor{ 








public boolean preHandle(HttpServletRequest request, 
HttpServletResponse response,Object handler)throws Exception{ { 
long startTime = System.currentTimeMillis(); 
request.setAttribute("startTime" ,startTime); 
return true; 
} 
public void postHandle(HttpServletRequest 
request, HttpServletResponse response, 
Object handler,ModelAndView modelAndView)throws 
Exception{ 
long startTime = (Long)request.getAttribute("startTime"); 
request.removeAttribute("startTime"); 
long endTime = System.currentTimeMillis(); 
modelAndView.addObject("handlingTime",endTime-startTime); 
} 
public void afterCompletion(HttpServletRequest request, 


HttpServletResponse response,Object handler,Exception ex)throws 


Exception{ 
} 

} 

在 这 个 拦截 器 的 preHandler0 方 法 中 ， 你 记录 了 起 始 时 间 ， 并 将 它 
保存 到 请 求 属性 中 。 这 个 方法 应 该 返回 true， 人 允许 DispatcherServlet 继 续 
处 理 请 求 。 否 则 ，DispatcherServlet 会 认为 这 个 方法 已 经 处 理 了 请 求 ， 直 
接 将 响应 返回 给 用 户 。 然 后 ， 在 postHandler0) 方 法 中 ， 从 请 求 属 性 中 加 
载 起 始 时 间 ， 并 将 它 与 当前 时 间 进 行 比较 。 你 可 以 计算 总 的 持续 时 间 ， 
然后 把 这 个 时 间 添 加 到 模型 中 ， 传 递 给 视图 。 最 后 ，afterCompletion() 
方法 无 事 可 做 ， 空 着 就 可 以 了 。 

11.4.7 逻辑 处 于 


对 于 逻辑 处 理 其 实 是 通过 适配器 中 转调 用 Handler 并 返回 视图 的 ， 
对 应 代码 : 


mV = ha.handle(processedRequest, response, 











mappedHandler.getHandler()); 
同样 ， 还 是 以 引导 示例 为 基础 进行 处 理 逻 辑 分 析 ， 之 前 分 析 过 ， 对 
普通 的 Web 请 求 ，Spring 默 认 使 用 SimpleControllerHandlerAdapter 类 
进行 处 理 ， 我 们 进入 SimpleControllerHandlerAdapter 类 的 handle 方 法 如 
PF: 
public ModelAndView handle(HttpServletRequest request, 





HttpServletResponse response, 
Object handler) 
throws Exception 1 
return ((Controller) handler).handleRequest(request, response); 
j 
但 是 回顾 引导 示例 中 的 UserController， 我 们 的 逻辑 是 写 在 








RE 全 个 是 handleRequest 函 数 ， 所 以 我 们 还 需 
进一步 分 析 这 期 间 所 包含 的 处 理 流程 。 
public ModelAndView handleRequest(HttpServletRequest request, 
HttpServletResponse response) 
throws Exception { 
// Delegate to WebContentGenerator for checking and preparing. 
checkAndPrepare(request, response, this instanceof LastModified); 
/如 果 需 要 session 内 的 同步 执行 
if (this.synchronizeOnSession) { 
HttpSession session = request.getSession(false); 
if (session != null) { 
Object mutex = WebUtils.getSessionMutex(session); 
synchronized (mutex) { 
1/ 调用 用 户 的 逻辑 


return handleRequestInternal(request, response); 


} 
FRE FH P 3E RE 
return handleRequestInternal(request, response); 


} 
11.4.8 异常 视图 的 处 于 


有 时 候 系 统 运行 过 程 中 出 现 异常 ， 而 我 们 并 不 希望 束 此 中 断 对 用 户 
的 服务 ， 而 是 至 少 告知 客户 当前 系统 在 处 理 逻 辑 的 过 程 中 出 现 了 异常 
i a a Spring 中 的 异常 处 理 机 制 会 帮 我 们 
完成 这 个 工作 。 这 里 Spring 主要 的 工作 束 是 将 逻辑 引导 至 








HandlerExceptionResolver 类 的 resolveException 方 法 ， 而 
HandlerExceptionResolver 的 使 用 ， 我 们 在 讲解 WebApplicationContext 的 
初始 化 的 时 候 已 经 介绍 过 了 。 
protected ModelAndView processHandlerException(HttpServletRequest 
request, HttpServletResponse 
response, 
Object handler, Exception ex) throws Exception { 
// Check registered HandlerExceptionResolvers... 
ModelAndView exMv = null; 
for (HandlerExceptionResolver handlerExceptionResolver : 


this.handlerException 
Resolvers) { 


exMv =handlerExceptionResolver.resolveException(request, 
response, handler, ex); 
if (exMv != null) { 
break; 


} 
if (exMv != null) { 
if (exMv.isEmpty()) { 
return null; 
} 
// We might still need view name translation for a plain error 
model... 
if (lex Mv.hasView()) { 


exMv.set ViewName(getDefault ViewName(request)); 
} 
if (logger.isDebugEnabled()) 1 
logger.debug("Handler execution resulted in exception - 
forwarding to 
resolved error view: " + exMv, ex); 


j 
WebUtils.exposeErrorRequestAttributes(request, ex, 


getServletName()); 
return exMv; 
} 
throw ex; 
} 
11.4.9 根据 视图 跳 转 页 


无 论 是 一 个 系统 还 是 一 个 站 点 ， 最 和 章 要 的 工作 都 是 与 用 户 进行 交 
互 ， 用 户 操 作 系 统 后 无 论 下 发 的 命令 成 功 与 否 都 需要 给 用 户 一 个 反馈 ， 
以 便于 用 户 进 行 下 一 步 的 判断 。 所 以 ， 在 逻辑 处 理 的 最 后 一 定 会 涉及 一 
个 页 面 跳 转 的 问题 。 
protected void render(ModelAndView mv, HttpServletRequest request, 
HttpServletResponse 
response) throws Exception { 
// Determine locale for request and apply it to the response. 
Locale locale = this.localeResolver.resolveLocale(request); 
response.setLocale(locale); 
View view; 


if (mv.isReference()) { 


// We need to resolve the view name. 
view -resolveViewName(mv.getViewNamer(), 
mv.getModelInternal(), locale, request); 
if (view == null) { 
throw new ServletException( 
"Could not resolve view with name " + mv.getViewName() + ” 
in servlet with name " + 


getServletName() + '"""); 


} 
else { 
// No need to lookup: the ModelAndView object contains the 
actual View object. 
view = mv.get View(); 
if (view == null) { 
throw new ServletException("ModelAndView [" + mv + "] 
neither contains 
a view name nora " + 


"View object in servlet with name ™ + getServletName() + '"""); 


j 
// Delegate to the View object for rendering. 
if (logger.isDebugEnabled()) 1 
logger.debug(" Rendering view [" + view + "| in DispatcherServlet 
with name 


™ + getServletName() + '""); 


view.render(mv.getModelInternal(), request, response); 
j 
1. 解析 视图 名 称 
在 上 文中 我 们 提 到 DispatcherServlet 会 根据 ModelAndView 选 择 合适 
ALAR BET ER, Tx — D) Fe Wh ze HEresolve ViewName R Zi rP 5c py, 
的 。 
protected View resolveViewName(String viewName, Map<String, 
Object> model, Locale locale, 
HttpServletRequest request) throws Exception { 
for (ViewResolver viewResolver : this.viewResolvers) { 
View view = viewResolver.resolve ViewName(viewName, locale); 
if (view != null) { 


return view; 


} 
return null; 

} 

我 们 以 
org.Springframework.web.servlet.view.InternalResourceViewResolver 为 例 
来 分 析 ViewResolver 逻 辑 的 解析 过 程 ， 其 中 resolveViewName 函 数 的 实现 
是 在 其 父 类 AbstractCaching ViewResolver 中 完成 的 。 

public View resolveViewName(String viewName, Locale locale) throws 
Exception { 

if ('isCache()) { 
/不 存在 绥 存 的 情况 下 直接 创建 视图 


return create View(viewName, locale); 


else { 
/直接 从 缓存 中 提取 
Object cacheKey = getCacheKey(viewName, locale); 
synchronized (this.viewCache) { 
View view = this.viewCache.get(cacheKey); 
if (view == null && (!this.cacheUnresolved || !this.viewCache. 
containsKey(cacheKey))) { 
// Ask the subclass to create the View object. 
view = createView(viewName, locale); 
if (view != null || this.cacheUnresolved) { 
this.viewCache.put(cacheKey, view); 
if (logger.isTraceEnabled()) { 


logger.trace("Cached view [" + cacheKey + "]"); 


} 


return view; 


} 
1E 2 2SUrIBasedViewResolverHi Œ f createViewEK Z5 . 
protected View createView(String viewName, Locale locale) throws 
Exception 1 
ITUR 2 RU PRAT AEA SC FE 2 AI AENT s UW ViewName Vy 4: 558 DU 
if (!canHandle(viewName, locale)) { 


return null; 


// 处 理 前 级 为 redirect:xx 的 情况 
if (viewName.startsWith(REDIRECT_URL_PREFIX)) { 
String redirectUrl = 
viewName.substring(REDIRECT_URL_PREFIX.length()); 
RedirectView view = new Redirect View(redirectUrl, 
isRedirectContext 
Relative(), isRedirectHttp10Compatible()); 
return applyLifecycleMethods(viewName, view); 
} 
HAERA A forward: xx 的 情况 
if (viewName.startsWith(FORWARD_URL_PREFIX)) { 
String forwardUrl = 
viewName.substring(FORWARD URL PREFIX.length()); 
return new InternalResourceView(forwardUrl); 
j 
// Else fall back to superclass implementation: calling loadView. 
return super.createView(viewName, locale); 
j 
protected View createView(String viewName, Locale locale) throws 
Exception 1 
return loadView(viewName, locale); 
j 
protected View loadView(String viewName, Locale locale) throws 
Exception 1 
AbstractUrlBasedView view = buildView(viewName); 
View result = applyLifecycleMethods(viewName, view); 


return (view.checkResource(locale) ? result : null); 


} 
protected AbstractUrlBasedView buildView(String viewName) throws 


Exception 1 
AbstractUrlBasedView view = (AbstractUrlBasedView) 
BeanUtils.instantiateClass 
(getViewClass()); 
/添加 前 缀 以 及 后 组 
view.setUrl(getPrefix() + viewName + getSuffix()); 
String contentType = getContentType(); 
if (contentType != null) { 
//¥ E. ContentType 
view.setContentType(contentType); 
} 
view.setRequestContextAttribute(getRequestContextAttribute()); 
view.setAttributesMap(getAttributesMap()); 
if (this.exposePathVariables != null) { 
view.setExposePathVariables(exposePath Variables); 


} 


return view; 


} 
通读 以 上 代码 ， 我 们 发 现 对 于 InternalResourceViewResolver 所 提供 


的 解析 功能 主要 考虑 到 了 几 个 方面 的 处 理 。 
基于 效率 的 考虑 ， 提 供 了 缓存 的 文 持 。 
提供 了 对 redirect:xx 和 forward:xx 前 缀 的 支持 。 
添加 了 前 级 及 后 级 ， 并 向 View 中 加 入 了 必需 的 属性 设置 。 


2. 页 面 跳 转 
当 通 过 viewName 解 析 到 对 应 的 View 后 ， 就 可 以 进一步 地 处 理 跳 转 


逻辑 了 。 
public void render(Map<String, ?> model, HttpServletRequest request, 
HttpServletResponse 
response) throws Exception { 
if (logger.isTraceEnabled()) { 
logger.trace(" Rendering view with name "' * this.beanName + ” 
with model " + model + 
" and static attributes " + this.staticAttributes); 
} 
Map<String, Object> mergedModel = 
createMergedOutputModel(model, request, 
response); 
prepareResponse(request, response); 
renderMergedOutputModel(mergedModel, request, response); 
} 
在 引导 示例 中 ， 我 们 了 解 到 对 于 ModelView 的 使 用 ， 可 以 将 一 些 属 
性 直接 放 入 其 中 ， 然 后 在 页 面 上 直接 通过 JSTL 语 法 或 者 原始 的 request 获 
取 。 这 是 一 个 很 方便 也 很 神奇 的 功能 ， 但 是 实现 却 并 不 复杂 ， 无 非 是 把 
我 们 将 要 用 到 的 属性 放 入 request 中 ， 以 便 在 其 他 地 方 可 以 直接 调用 ， 
而 解析 这 些 属性 的 工作 就 是 在 createMergedOutputModel 函 数 中 完成 的 。 
protected Map<String, Object> createMergedOutputModel(Map<String, 





?» model, HttpServletRequest 
request, 
HttpServletResponse response) { 
@SuppressWarnings("unchecked") 
Map<String, Object> pathVars = this.exposePathVariables ? 
(Map<String, Object>) 


request.getAttribute(View.PATH VARIABLES) : null; 
// Consolidate static and dynamic model attributes. 
int size = this.staticAttributes.size(); 
size += (model != null) ? model.size() : 0; 
size += (pathVars != null) ? pathVars.size() : 0; 
Map<String, Object> mergedModel = new HashMap<String, Object> 
(size); 
mergedModel.putAll(this.staticAttributes); 
if (pathVars != null) { 
mergedModel.putAll(pathVars); 
j 
if (model !- null) { 
mergedModel.putAll(model); 
j 
// Expose RequestContext? 
if (this.requestContextAttribute != null) { 
mergedModel.put(this.requestContextAttribute, 
createRequestContext(request, 
response, mergedModel)); 
} 
return mergedModel; 
} 
/处 理 页 面 跳 转 
protected void renderMergedOutputModel( 
Map<String, Object> model, HttpServletRequest request, 
HttpServletResponse 


response) throws Exception { 


// Determine which request handle to expose to the 
RequestDispatcher. 
HttpServletRequest requestloExpose = 
getRequestToExpose(request); 
/将 model 中 的 数据 以 属性 的 方式 设置 到 request 中 
exposeModelAsRequestAttributes(model, requestToExpose); 
// Expose helpers as request attributes, if any. 
expose Helpers(request ToExpose); 
// Determine the path for the request dispatcher. 
String dispatcherPath = prepareForRendering(requestToExpose, 
response); 
// Obtain a RequestDispatcher for the target resource (typically a 
JSP). 
RequestDispatcher rd = getRequestDispatcher(request 'oExpose, 
dispatcherPath); 
if (rd == null) { 
throw new ServletException("Could not get RequestDispatcher for 
[" + getUrlQ + 
"]: Check that the corresponding file exists within your web 
application archive!"); 
j 
// If already included or response already committed, perform 
include, else forward. 
if (useInclude(requestToExpose, response)) 1 
response.setContentType(getContentType()); 
if (logger.isDebugEnabled()) { 


logger.debug("Including resource [" + getUrl() + "] in Internal 


ResourceView "' + getBeanName() + """); 
j 
rd.include(requestl'oExpose, response); 
j 
else { 
// Note: The forwarded resource is supposed to determine the 
content type itself. 
exposeForwardRequestAttributes(request 'oExpose); 
if (logger.isDebugEnabled()) { 
logger.debug(" Forwarding to resource [" + getUrl() + "] in 
InternalResourceView " + getBeanName() + """); 
j 


rd.forward(request T oExpose, response); 


Java 远 程 方法 调用 ， 即 JavaRMI (Java Remote Method 
Invocation) ， 是 Java 编 程 语言 里 一 种 用 于 实现 远程 过 程 调 用 的 应 用 程序 
编程 接口 。 它 使 客户 机 上 运行 的 程序 可 以 调用 远程 服务 器 上 的 对 象 。 远 
s oon MM RMI 全 部 
的 宗旨 就 是 尽 可 能 地 简化 远程 接口 对 象 的 使 用 。 

Java RMI 极 大 地 依赖 于 接口 。 在 需要 创建 一 个 远程 对 象 时 ， 程 序 员 
通过 传递 一 个 接口 来 隐藏 底层 的 实现 细节 。 客 户 端 得 到 的 远程 对 象 句 柄 
正好 与 本 地 的 根 代 码 连接 ， 由 后 者 负责 透 过 网 络 通信 。 这 样 一 来 ， 程 序 
员 只 需 关 心 如 何 通过 自己 的 接口 句柄 发 送 消 息 。 











12.1 RMI 
在 Spring 中 ， 同 样 提供 了 对 RMI 的 文 持 ， 使 得 在 Spring 下 的 RMI 开 发 
变 得 更 方便 ， 同 样 ， 我 们 还 是 通过 示例 来 快速 体验 RMI 所 提供 的 功能 。 
12.1.1 ZN 4 


以 下 提供 了 Spring 整合 RMI 的 使 用 示例 。 
(1) 建立 RMI 对 外 接口 。 
public interface HelloRMIService { 





public int getAdd(int a, int b); 
} 
(2) 建立 接口 实现 类 。 
public class HelloRMIServiceImpl implements HelloRMIService { 





public int getAdd(int a, int b) { 


return a + b; 


} 
(3) 建立 服务 端 配置 文件 。 

<?xml version="1.0" encoding="UTF-8"?> 

«beans xmlns="http://www.Springframework.org/schema/beans" 
xmins:xsi-"http://www.w3.org/2001/XMLSchema-instance" 

xsi:schemaLocation-" 

http://www.Springframework.org/schema/beans 
http://www.Springframework.org/schema/beans/Spring-beans-3.0.xsd 

i 
<!-- 服 务 端 --> 

<bean id-"helloRMIServiceImpl" 


class-"test.remote. HelloRMIServiceImpl" /> 
<!-- 将 类 为 一 个 RMI 服 务 --> 
<bean id="myRMI" 


class="org.Springframework.remoting.RMI.RMIServiceExporter"> 


<1-- 服 务 类 --> 

<property name="service" ref-"helloRMIServiceImpl" /> 
<!-- 服 务 名 --> 

<property name="serviceName" value="helloRMI" /> 
<!-- 服 务 接口 --> 


<property name-"servicelInterface" 
value="test.remote.HelloRMIService" /> 
<!-- 服 务 端口 --> 
<property name="registryPort" value="9999" /> 
<!-- 其 他 属性 自己 查看 
org.Springframework.remoting.RMI.RMIServiceExporter If] Z5, 3t 
知道 支持 的 属性 了 --> 
</bean> 
</beans> 
(4) 建 并 服务 端 测试 。 
public class ServerTest { 
public static void main(String[] args) { 
new 
ClassPathXmlApplicationContext("test/remote/RMIServer.xml"); 
} 
} 
到 这 里 ， 建 立 RMI ARAMA OROAZR S. Wgm LAS 
两 数 相 加 的 对 外 接口 供 其 他 服务 器 调用 。 局 动 服务 端 测试 类 ， 其 他 机 器 


或 端口 便 可 以 通过 RMI 来 连接 到 本 机 了 。 
(50 完成 了 服务 端的 配置 后 ， 还 需要 在 测试 端 建 并 测试 环境 以 及 
测试 代码 。 首 先 建立 测试 端 配置 文件 。 
<?xml version="1.0" encoding="UTF-8"?> 
«beans xmlIns="http://www.Springframework.org/schema/beans" 
xmins:xsi-"http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation-" 
http://www.Springframework.org/schema/beans 
http://www.Springframework.org/schema/beans/Spring-beans-3.0.xsd 
"> 
<!-- 客 户 端 --> 
<bean id="myClient" 
class="org.Springframework.remoting.RMI.RMIProxyFactoryBean"> 
«property name="serviceUrl" 
value="RMI://127.0.0.1:9999/helloRMI"/> 
<property name="servicelnterface" 
value="test.remote.HelloRMIService"/> 
</bean> 
</beans> 
(6) 编写 测试 代码 。 
public class ClientTest { 
public static void main(String[] args) 1 
ApplicationContext context = new 
ClassPathXmlApplicationContext ("test/remote/ 
RMIClient.xml"); 
HelloRMIService hms = context.getBean(" myClient", 
HelloRMIService.class); 


System.out.printIn(hms.getAdd(1, 2)); 


} 

通过 以 上 的 步骤 ， 实 现 了 测试 端的 代码 调用 。 你 会 看 到 测试 端 通过 
RMI 进 行 了 远程 连接 ， 连 接 到 了 服务 端 ， 并 使 用 对 应 的 实现 类 
HelloRMIServiceImpl 中 提供 的 方法 getAdd 来 计算 参数 并 返回 结果 ， 你 会 
看 到 控制 台 输 出 了 3。 当 然 以 上 的 测试 用 例 是 使 用 同一 侣 机 器 不 同 的 端 
口 来 模拟 不 同 机 器 的 RMI 连 接 。 在 企业 应 用 中 一 般 都 是 使 用 不 同 的 机 器 
来 进行 RMI 服 务 的 发 布 与 访问 ， 你 需要 将 接口 打包 ， 并 放置 在 服务 端的 
工程 中 。 

这 是 一 个 简单 的 方法 展示 ， 但 是 却 很 好 地 展示 了 Spring 中 使 用 RMI 
的 流程 以 及 步骤 ， 如 果 抛 弃 Spring 而 使 用 原始 的 RMI 发 布 与 连接 ， 则 会 
是 一 件 很 抹 烦 的 事情 ， 有 兴趣 的 读者 可 以 查阅 相关 的 资料 。 在 Spring 中 
使 用 RMI 非 常 简 单 ，Spring 帮 助 我 们 做 了 大 量 的 工作 ， 这 些 工作 都 包括 
什么 呢 ? 接 下 来 我 们 一 起 深入 分 析 Spring 中 对 RMI 功 能 的 实现 原理 。 

12.1.2 服务 端 实现 

自 先 我 们 从 服务 端的 发 布 功能 开始 着 手 ， 同 样 ，Spring 中 的 核心 还 
是 配置 文件 ， 这 是 所 有 功能 的 基础 。 在 服务 端的 配置 文件 中 我 们 可 以 看 
到 ， 和 定义 了 两 个 bean， 其 中 一 个 是 对 接口 实现 类 的 发 布 ， 而 另 一 个 则 是 
对 RMI 服 务 的 有 发布， 使 用 
org.Springframework.remoting.RMI.RMIServiceExporter 类 进行 封装 ， 其 
中 包括 了 服务 类 、 服 务 名 、 服 务 接 口 、 服 务 端口 等 若干 属性 ， 因 此 我 们 
可 以 断定 ， org.Springframework.remoting.RMI.RMIServiceExporter 类 应 
该 是 发 布 RMI 的 关键 类 。 我 们 可 以 从 此 类 入 手 进行 分 析 。 

根据 前 面 展 示 的 示例 ， 启 动 Spring 中 的 RMI 服 务 并 没有 多 余 的 操 
作 ， 仅 仅 是 开局 Spring 的 环境 : new 














ClassPathXmlApplicationContext("test/remote/RMIServer.xml")， 仪 此 一 
句 。 于 是 ， 我 们 分 析 很 可 能 是 RMIServiceExportern 在 初始 化 的 时 候 做 了 
某 些 操作 完成 了 端口 的 发 布 功能 ， 那 么 这 些 操作 的 入 口 是 在 这 个 类 的 哪 
个 方法 里 面 呢 ? 

进入 这 个 类 ， 首 先 分 析 这 个 类 的 层次 结构 ， 如 图 12-1 所 示 。 
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图 12-1 RMIServiceExporter 类 层次 结构 图 


根据 Eclipse 提 供 的 功能 ， 我 们 查看 到 了 RMIServiceExporter 的 层次 
结构 图 ， 那 么 从 这 个 层次 图 中 我 们 能 得 到 什么 信息 呢 ? 

RMIServiceExporter 实现 了 Spring 中 几 个 比较 敏感 的 接口 : 
BeanClassLoaderAware、DisposableBean、InitializingBean， 其 中 ， 
DisposableBean 接 口 保 证 在 实现 该 接口 的 bean 销 毁 时 调用 其 destroy 方 
法 ，BeanClassLoaderAware 接 口 保证 在 实现 该 接口 的 bean 的 初始 化 时 调 
用 其 setBeanClassLoader 方 法 ， 而 PnitializingBean 接 口 则 是 保证 在 实现 该 
接口 的 bean 初 始 化 时 调用 其 afterPropertiesSet 方法 ， 所 以 我 们 推断 
RMIServiceExporter 的 初始 化 函数 入 口 一 定 在 其 afterPropertiesSet 或 者 
setBeanClassLoader 方法 中 。 经 过 碍 看 代码 ， 确 认 afterPropertiesSet 为 
RMIServiceExporter 功 能 的 初始 化 入 口 。 

















public void afterPropertiesSet() throws RemoteException { 
prepare(); 
} 
public void prepare() throws RemoteException { 
/检查 验证 service 
checkService(); 
if (this.serviceName == null) { 
throw new IllegalArgumentException("Property 'serviceName' is 
required"); 
j 
/如 采用 户 在 配置 文件 中 配置 了 clientSocketFactory 或 者 
serverSocketFactory 的 处 理 
/* 
* 如 果 配 置 中 的 clientSocketFactory 同 时 又 实现 了 
RMIServerSocketFactory 接 口 那么 会 忽略 
* 配置 中 的 serverSocketFactory 而 使 用 clientSocketFactory 代 蔡 
*/ 
if (this.clientSocketFactory instanceof RMIServerSocketFactory) { 








this.serverSocketFactory = (RMIServerSocketFactory) 

this.clientSocketFactory; 

} 

/clientSocketFactory 和 serverSocketFactory 要 么 同时 出 现 要 么 都 不 
出 现 

if ((this.clientSocketFactory != null && this.serverSocketFactory == 
null) || 

(this.clientSocketFactory == null && this.serverSocketFactory != 
null)) { 


throw new IllegalArgumentException( 
"Both RMIClientSocketFactory and RMIServerSocketFactory or 
none 


required"); 


* 如 果 配 置 中 的 registryClientSocketFactory 同 时 实现 了 
RMIServerSocketFactory 接 口 那 么 
* 会 忽略 配置 中 的 registryServerSocketFactory 而 使 用 
registryClientSocketFactory{t $i 
*/ 
if (this.registryClientSocketFactory instanceof 
RMIServerSocketFactory) { 
this.registryServerSocketFactory = (RMIServerSocketFactory) 
this.registry 
ClientSocketFactory; 
} 
/不 允许 出 现 只 配置 registryServerSocketFactory 却 没有 配置 
registryClientSocketFactory 的 
情况 出 现 
if (this.registryClientSocketFactory == null && 
this.registryServerSocket 
Factory != null) { 
throw new IllegalArgumentException( 
"RMIServerSocketFactory without RMIClientSocketFactory for 
registry not supported"); 


this.createdRegistry = false; 
/确定 RMI registry 
if (this.registry == null) { 
this.registry = getRegistry(this.registryHost, this.registryPort, 
this.registryClientSocketFactory, 
this.registryServerSocketFactory); 
this.createdRegistry = true; 
} 
/初始 化 以 及 缓存 导出 的 Object 
/此 时 通常 情况 下 是 使 用 RMIInvocationWrapper 封 装 的 JDK 代 理 
类 ， 切 面 为 RemoteInvocation 
TraceInterceptor 
this.exportedObject = getObjectToExport(); 
if (logger.isInfoEnabled()) { 
logger.info("Binding service " + this.serviceName + "to RMI 
registry: " 
+ this.registry); 
} 
// Export RMI object. 
if (this.clientSocketFactory != null) { 
/* 
* 使 用 由 给 定 的 套 接 字 工厂 指定 的 传送 方式 导出 远程 对 象 ， 
以 便 能 够 接收 传 入 的 调用 。 
* ClientSocketFactory: 进 行 远程 对 象 调用 的 客户 端 套 接 字 工厂 
* serverSocketFactory: 接 收 远 程 调用 的 服务 端 套 接 字 工厂 
*/ 
UnicastRemoteObject.exportObject( 


this.exportedObject, this.servicePort, this.clientSocketFactory, 
this.serverSocketFactory); 

} 

else { 
// tH remote object, 以 使 它 能 接收 特定 端口 的 调用 
UnicastRemoteObject.exportObject(this.exportedObject, 

this.servicePort); 

} 

try { 
if (this.replaceExistingBinding) { 


this.registry.rebind(this.serviceName, this.exportedObject); 


} 
else { 
/ 绑 定 服务 名 称 到 remote object, Yh Ft Val H serviceName 的 时 
候 会 被 exportedObject 
接收 
this.registry.bind(this.serviceName, this.exportedObject); 
} 


} 

catch (AlreadyBoundException ex) { 
unexportObjectSilently(); 
throw new IllegalStateException( 


"Already an RMI object bound for name "' + this.serviceName + 


"+ ex.toString()); 
j 


catch (RemoteException ex) 1 


unexportObjectSilently(); 


throw ex; 


} 

果然 ， 在 afterPropertiesSet 函 数 中 将 实现 委托 给 了 prepare， 而 在 
prepare 方 法 中 我 们 找到 了 RMI 服 务 发 布 的 功能 实现 ， 同 时 ， 我 们 也 大 致 
清楚 了 RMI 服 务 发 布 的 流程 。 

(1) 验证 service。 

此 处 的 service 对 应 的 是 配置 中 类 型 为 RMIServiceExporter 的 service 属 
性 ， 它 是 实现 类 ， 并 不 是 接口 。 尽 管 后 期 会 对 RMIServiceExporter 做 一 
系列 的 封装 ， 但 是 ， 无 论 怎 么 封装 ， 最 终 还 是 会 将 逻辑 引 癌 至 
RMIServiceExporter 来 处 理 ， 所 以 ， 在 发 布 之 前 需要 进行 验证 。 

(2) 处 理 用 户 自 定 义 的 SocketFactory 属 性 。 

在 RMIServiceExporter 中 提供 了 4 个 套 接 字 工厂 配置 ， 分 别 是 
clientSocketFactory. serverSocket Factory 和 registryClientSocketFactory、 
registryServerSocketFactory。 那 么 这 两 对 配置 又 有 什么 区 别 或 者 说 分 别 
是 应 用 在 什么 样 的 不 同 场景 呢 ? 

registryClientSocketFactory 与 registryServerSocketFactory 用 于 主机 与 
RMI 服 务 器 之 间 连 接 的 创建 ， 也 就 是 当 使 用 
LocateRegistry.createRegistry(registryPort, clientSocketFactory, server 
SocketFactory) 方 法 创建 Registry 实 例 时 会 在 RMI 主 机 使 用 
serverSocketFactory 创 建 套 接 字 等 得 连接 ， 而 服务 端 与 RMI 主 机 通信 时 会 
使 用 clientSocketFactory 创 建 连接 套 接 字 。 

clientSocketFactory、 serverSocketFactory 同样 是 创建 套 接 字 ， 但 是 
使 用 的 位 置 不 同 ， clientSocketFactory、serverSocketFactory 用 于 导出 远 
程 对 象 ，serverSocketFactory 用 于 在 服务 端 建 立 套 接 字 等 竺 客户 端 连 
接 ， 而 clientSocketFactory 用 于 调用 端 建立 套 接 字 发 起 连接 。 











(3) 根据 配置 参数 获取 Registry。 
C4) 构造 对 外 发 布 的 实例 。 
构建 对 外 发 布 的 实例 ， 当 外 界 通过 注册 的 服务 名 调用 啊 应 的 方法 
时 ，RMI 服 务 会 将 请 求 引 入 此 类 来 处 理 。 
(50 发 布 实例 。 
在 发 布 RMI 服 务 的 流程 中 ， 有 几 个 步骤 可 能 是 我 们 比较 关心 的 。 
1. 获取 registry 
对 RMI 稍 有 了 解 就 会 知道 ， 由 于 底层 的 封装 ， 获 取 Registry 实 例 是 
非常 简单 的 ， 只 需要 使 用 一 个 函数 LocateRegistry.createRegistry(...) 创 建 
Registry 实 例 就 可 以 了 。 但 是 ，Spring 中 并 没有 这 么 做 ， 而 是 考虑 得 更 
多 ， 比 如 RMI 注册 主机 与 发 布 的 服务 并 不 在 一 台 机 右上 ， 那 么 需要 使 
用 LocateRegistry.getRegistry(registryHost, registryPort, 
clientSocketFactory) 去 远程 获取 Registry 实 例 。 
protected Registry getRegistry(String registryHost, int registryPort, 
RMIClientSocketFactory clientSocketFactory, RMIServerSocketFactory 
serverSocketFactory) 
throws RemoteException 1 
if (registryHost != null) { 
/远程 连接 测试 
if (logger.isInfoEnabled()) { 
logger.info(" Looking for RMI registry at port " + registryPort + 


of host [" + registryHost + "]"); 
} 
/如 果 registryHost 不 为 空 则 答 试 获取 对 应 主机 的 Registry 
Registry reg = LocateRegistry.getRegistry(registryHost, 
registryPort, 


clientSocketFactory); 
testRegistry(reg); 
return reg; 
}else { 
/获取 本 机 的 Registry 
return getRegistry(registryPort, clientSocketFactory, 
serverSocketFactory); 
} 

} 

如 果 并 不 是 从 另外 的 服务 器 上 获取 Registry 连 接 ， 那 么 就 需要 在 本 
地 创建 RMI 的 Registry 实 例 了 。 当 然 ， 这 里 有 一 个 关键 的 参数 
alwaysCreateRegistry， 如 果 此 参数 配置 为 tue， 那 么 在 获取 Registry 实 例 
时 会 首先 测试 是 否 已 经 建 并 了 对 指定 端口 的 连接 ， 如 有 果 已 经 建立 则 复 用 
己 经 创建 的 实例 ， 否 则 重新 创建 。 

当然 ， 之 前 也 提 到 过 ， 创 建 Registry 实 例 时 可 以 使 用 自 定 义 的 连接 
工厂 ， 而 之 前 的 判断 也 保证 了 clientSocketFactory 与 serverSocketFactory 
要 么 同时 出 现 ， 要 么 同时 不 出 现 ， 所 以 这 里 只 对 clientSocketFactory 是 否 
为 空 进行 了 判断 。 

protected Registry getRegistry( 











int registryPort, RMIClientSocketFactory clientSocketFactory, 
RMIServerSocketFactory 
serverSocketFactory) 
throws RemoteException 1 
if (clientSocketFactory != null) { 
if (this.alwaysCreateRegistry) 1 
logger.info(" Creating new RMI registry"); 
/使 用 clientSocketFactory 创 建 Registry 


serverSocketFactory); 
return LocateRegistry.createRegistry(registryPort, 
clientSocketFactory, 
} 
if (logger.isInfoEnabled()) { 
logger.info(" Looking for RMI registry at port " + registryPort + 


using custom socket factory"); 
} 
synchronized (LocateRegistry.class) { 
try { 
// 复 用 测试 
Registry reg = LocateRegistry.getRegistry(null, registryPort, 
clientSocketFactory); 
testRegistry(reg); 
return reg; 
} 
catch (RemoteException ex) { 
logger.debug("RMI registry access threw exception", ex); 


logger.info("Could not detect RMI registry - creating new 


one"); 
return LocateRegistry.createRegistry(registry Port, 
clientSocketFactory, 
serverSocketFactory); 
} 
} 


}else { 


return getRegistry(registryPort); 


} 
如 果 创 建 Registry 实例 时 不 需要 使 用 自 定义 的 套 接 字 工厂 ， 那 么 就 
可 以 直接 使 用 LocateRegistry.createRegistry(..) 方 法 来 创建 了 ， 当 然 复 用 
的 检测 还 是 必要 的 。 
protected Registry getRegistry(int registryPort) throws 
RemoteException { 
if (this.alwaysCreateRegistry) { 
logger.info("Creating new RMI registry"); 
return LocateRegistry.createRegistry(registryPort); 
} 
if (logger.isInfoEnabled()) { 
logger.info("Looking for RMI registry at port " + registryPort + 


nnn. 
, 


synchronized (LocateRegistry.class) 1 
try 1 
/查看 对 应 当前 registryPort 的 Registry 是 否 已 经 创建 ， 如 果 创 
建 直接 使 用 
Registry reg = LocateRegistry.getRegistry(registryPort); 
1/ 测试 是 否 可 用 ， 如 果 不 可 用 则 抛 出 异常 
testRegistry(reg); 





return reg; 
} 
catch (RemoteException ex) { 


logger.debug("RMI registry access threw exception", ex); 


logger.info("Could not detect RMI registry - creating new one"); 
/根据 端口 创建 Registry 
return LocateRegistry.createRegistry(registryPort); 


} 
2. 初始 化 将 要 导出 的 实体 对 象 
之 前 有 提 到 过 ， 当 请 求 某 个 RMI 服 务 的 时 候 ，RMI 会 根据 注册 的 服 
务 名 称 ， 将 请 求 引 导 人 至 远程 对 象 处 理 类 中 ， 这 个 处 理 类 便 是 使 用 
getObjectToExport() 进 行 创建 。 
protected Remote getObjectToExport() { 
// 如 果 配 置 的 service 属 性 对 应 的 类 实现 了 Remote 接 口 且 没有 配置 


serviceInterface 属 性 








if (getService() instanceof Remote && 
(getServiceInterface() == null || Remote.class.isAssignableFrom 
(getServiceInterface()))) 1 

return (Remote) getService(); 
j 
else { 

if (logger.isDebugEnabled()) { 

logger.debug("RMI service [" + getService() + "] is an RMI 
invoker"); 
} 
/对 service 进 行 封装 


return new RMIInvocationWrapper(getProxyForService(), this); 


请 求 处 理 类 的 初始 化 主要 处 理 规 则 为 : 如 果 配 置 的 service 属 性 对 应 
的 类 实现 了 Remote 接 口 且 没有 配置 serviceInterface 属性 ， 那 么 直接 使 用 
service 作为 处 理 类 ; 人 否则， 使 用 RMIInvocationWrapper 对 service 的 代理 
类 和 当前 类 也 就 是 RMIServiceExporter 进 行 封 装 。 

经 过 这 样 的 封装 ， 客 户 端 与 服务 端 便 可 以 达成 一 致 协议 ， 当 客户 站 
检测 到 是 RMIInvocation Wrapper 类 型 stub 的 时 候 便 会 直接 调用 其 invoke 
方法 ， 使 得 调用 端 与 服务 端 很 好 地 连接 在 了 一 起 。 而 
RMIInvocationWrapper 封装 了 用 于 处 理 请 求 的 代理 类 ， 在 invoke 中 便 会 
使 用 代理 类 进行 进一步 处 理 。 

之 前 的 逻辑 已 经 非常 清楚 了 ， 当 请 求 RMI 服 务 时 会 由 注册 表 
Registry 实 例 将 请 求 转 同 之 前 注册 的 处 理 类 去 处 理 ， 也 束 是 之 前 封装 的 
RMIInvocationWrapper， 然 后 由 RMIInvocationWrapper 中 的 invoke 方 法 进 
行 处 理 ， 那 么 为 什么 不 是 在 invoke 方 法 中 直接 使 用 service， 而 是 通过 代 
理 再 次 将 service 封 装 呢 ? 

这 其 中 的 一 个 关键 点 是 ， 在 创建 代理 时 添加 了 一 个 增强 拦截 器 
RemoteInvocationTraceInterceptor， 目 的 是 为 了 对 方法 调用 进行 打印 中 
踩 ， 但 是 如 果 直 接 在 invoke 方法 中 便 编 码 这 些 日 志 ， 会 使 代码 看 起 来 
很 不 优雅 ， 而 且 耦 合 度 很 高 ， 使 用 代理 的 方式 就 会 解雇 这样 的 问题 ， 而 
且 会 有 很 高 的 可 扩展 性 。 

protected Object getProxyForService() { 

/验证 service 


checkService(); 

















/验证 serviceInterface 

checkServiceInterface(); 

/使 用 JDK 的 方式 创建 代理 

ProxyFactory proxyFactory = new ProxyFactory(); 
/添加 代理 接口 


proxyFactory.addInterface(getServiceInterface()); 
if (this.registerTraceInterceptor != null ? 
this.registerTraceInterceptor.booleanValue() : this.interceptors == 
null) { 
/加 入 代理 的 横 切 面 RemoteInvocationTraceInterceptor 并 记录 
Exporter 名 称 
proxyFactory.addAdvice(new 
RemoteInvocationTraceInterceptor(getExporterName())); 
j 
if (this.interceptors != null) { 
AdvisorAdapterRegistry adapterRegistry — 
GlobalAdvisorAdapterRegistry. 
getInstance(); 


for (int i = 0; i < this.interceptors.length; i++) { 


proxyFactory.addAdvisor(adapterRegistry.wrap(this.interceptors|i])); 
} 
} 
/设置 要 代理 的 目标 类 
proxyFactory.setTarget(getService()); 
proxyFactory.setOpaque(true); 
/创建 代理 
return proxyFactory.getProxy(getBeanClassLoader()); 
} 
3. RMI 服 务 激 活 调用 
之 前 反复 提 到 过 ， 由 于 在 之 前 bean 初始 化 的 时 候 做 了 服务 名 称 绑 
定 this.registry.bind (this.serviceName, this.exportedObject)， 其 中 的 


exportedObject 其 实 是 被 RMIInvocationWrapper 进 行 过 封装 的 ， 也 就 是 说 
当 其 他 服务 器 调用 serviceName 的 RMI 服 务 时 ，Java 会 为 我 们 封装 其 内 部 
操作 ， 而 直接 会 将 代码 转向 RMIInvocationWrapper 的 invoke 方 法 中 。 
public Object invoke(RemoteInvocation invocation) 
throws RemoteException, NoSuchMethodException, 
IllegalAccessException, 
InvocationTargetException 1 
return this.RMIExporter.invoke(invocation, this.wrappedObject); 
j 
而 此 时 this.RMIExporter 为 之 前 初始 化 的 RMIServiceExporter， 
invocation 为 包含 着 需要 激活 的 方法 参数 ， 而 wrappedObject 则 是 之 前 封 
装 的 代理 类 。 
protected Object invoke(RemoteInvocation invocation, Object 
targetObject) 
throws NoSuchMethodException, IllegalAccessException, 
InvocationTargetException { 
return super.invoke(invocation, targetObject); 
} 
protected Object invoke(RemoteInvocation invocation, Object 
targetObject) 
throws NoSuchMethodException, IllegalAccessException, 
InvocationTargetException 1 
if (logger.isTraceEnabled()) 1 
logger.trace("Executing " + invocation); 
} 
try { 
return getRemoteInvocationExecutor().invoke(invocation, 


targetObject); 
} 
catch (NoSuchMethodException ex) { 
if (logger.isDebugEnabled()) 1 
logger.warn("Could not find target method for " + invocation, 
ex); 
j 
throw ex; 
j 
catch (IllegalAccessException ex) 1 
if (logger.isDebugEnabled()) { 
logger.warn("Could not access target method for " * invocation, 
ex); 
j 
throw ex; 
j 
catch (InvocationTargetException ex) 1 
if (logger.isDebugEnabled()) 1 
logger.debug(" Target method failed for " + invocation, 
ex.getTargetException()); 
} 


throw ex; 


} 

public Object invoke(RemoteInvocation invocation, Object 
targetObject) 

throws NoSuchMethodException, IllegalAccessException, 


InvocationTargetException{ 
Assert.notNull(invocation, "RemoteInvocation must not be null"); 
Assert.notNull(targetObject, "Target object must not be null"); 
/通过 反射 方式 激活 方法 
return invocation.invoke(targetObject); 
} 
public Object invoke(Object targetObject) 
throws NoSuchMethodException, IllegalAccessException, 
InvocationTarget 
Exception 1 
/根据 方法 名 称 获取 代理 中 对 应 的 方法 
Method method = 
targetObject.getClass().getMethod(this.methodName, this. 





parameterTypes); 
/执行 代理 中 的 方法 
return method.invoke(targetObject, this.arguments); 
} 
12.1.3 客户 端 实 现 


根据 客户 端 配置 文件 ， 锁 定 入 口 类 为 RMIProxyFactoryBean， 同 样 
根据 类 的 层次 结构 查找 入 口 函 数 ， 如 图 12-2 所 示 。 
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图 12-2 RMIProxyFactoryBean 类 的 层次 结构 图 


根据 层次 关系 以 及 之 前 的 分 析 ， 我 们 提取 出 该 类 实现 的 比较 重要 的 
接口 InitializingBean、BeanClassLoaderAware 以 及 MethodInterceptor。 
其 中 实现 了 TitializingBean， 则 Spring 会 确保 在 此 初始 化 bean 时 调用 
afterPropertiesSet 进 行 逻辑 的 初始 化 。 
public void afterPropertiesSet() { 
super.afterPropertiesSet(); 
if (getServiceInterface() == null) { 
throw new IllegalArgumentException(" Property 'serviceInterface' 
is 
required"); 
} 
1/ 根据 设 置 的 接口 创建 代理 ， 并 使 用 当前 类 this 作 为 增强 器 


this.serviceProxy = new ProxyFactory(getServicelnterface(), 
this).getProxy 
(getBeanClassLoader()); 
} 
EJI}, RMIProxyFactoryBean 又 实现 了 FactoryBean 接 口 ， 那 么 当 获 
取 bean 时 并 不 是 直接 获取 bean， 而 是 获取 该 bean 的 getObject 方 法 。 
public Object getObject() { 
return this.serviceProxy; 
} 
这 样 ， 我 们 似乎 已 近 形成 了 一 个 大 致 的 轮廓 ， 当 获取 该 bean 时 ， 首 
先 通过 afterPropertiesSet 创 建 代 理 类 ， 并 使 用 当前 类 作为 增强 方法 ， 而 在 
调用 该 bean 时 其 实 返回 的 是 代理 类 ， 既 然 调 用 的 是 代理 类 ， 那 么 又 会 
使 用 当前 bean 作为 增强 器 进行 增强 ， 也 就 是 说 会 调用 
RMIProxyFactoryBean 的 父 类 RMIClientInterceptor 的 invoke 方 法 。 
我 们 先 从 afterPropertiesSet 中 的 super.afterPropertiesSet() 方 法 开始 分 
析 。 


public void afterPropertiesSet() { 





super.afterPropertiesSet(); 
prepare(); 
} 
继续 仍 踩 代码， 发 现 父 类 的 父 类 ， 也 就 是 UrlBasedRemoteAccessor 
中 的 afterPropertiesSet 方 法 只 完成 了 对 serviceUrl 属 性 的 验证 。 
public void afterPropertiesSet() { 
if (getServiceUrl() == null) { 
throw new IllegalArgumentException(" Property 'serviceUrl' is 
required"); 


} 


} 

所 以 推 新 所 有 的 客户 端 都 应 该 在 prepare 方 法 中 实现 ， 继 续 碍 看 
prepare(). 

1. 通过 代理 拦截 并 获取 stub 

在 父 类 的 afterPropertiesSet 方 法 中 完成 了 对 serviceUrl 的 验证 ， 那 么 
Prepare 函 数 又 完成 了 什么 功能 呢 ? 


public void prepare() throws RemoteLookupFailureException { 





// Cache RMI stub on initialization? 
/如 果 配 置 了 lookupStubOnStartup 属 性 便 会 在 启动 时 寻找 stub 
if (this.lookupStubOnStartup) { 
Remote remoteObj = lookupStub(); 
if (logger.isDebugEnabled()) { 
if (remoteObj instanceof RMIInvocationHandler) { 
logger.debug("RMI stub [" + getServiceUrl() + "] is an RMI 
invoker"); 
} 
else if (getServiceInterface() != null) { 
boolean isImpl = getServicelInterface().isInstance(remoteObj); 
logger.debug("Using service interface [" + 
getServiceInterface(). 
getName() + 
"] for RMI stub [" + getServiceUrl() + "] - "+ 


(lisImpl ? "not " : "") + "directly implemented"); 


} 
if (this.cacheStub) { 


/将 获取 的 stub 绥 存 


this.cachedStub = remoteObj; 


} 

从 上 面 的 代码 中 ， 我 们 了 解 到 了 一 个 很 重要 的 属性 
lookupStubOnStartup， 如 果 将 此 属性 设置 为 tue， 那 么 获取 stub 的 工作 束 
会 在 系统 局 动 时 被 执行 并 缓存 ， 从 而 提高 使 用 时 候 的 响应 时 间 。 

获取 stub 是 RMI 应 用 中 的 关键 步骤 ， 当 然 你 可 以 使 用 两 种 方式 进 


/一 


介 。 





(1) 使 用 自 定 义 的 套 接 字 工厂 。 如 果 使 用 这 种 方式 ， 你 需要 在 构 
造 Registry “PING Ae MERE LA, HEH Registry Fie £C] 
lookup 方 法 来 获取 对 应 的 stub。 

(2) 直接 使 用 RMI 提 供 的 标准 方法 : 
Naming.lookup(getServiceUrl()). 








protected Remote lookupStub() throws RemoteLookupFailureException 


try 1 
Remote stub - null; 
if (this.registryClientSocketFactory !- null) 1 
URL url = new URL(null, getServiceUrl(), new 
DummyURLStreamHandler()); 
String protocol = url.getProtocol(); 
/验证 传输 协议 
if (protocol != null && !"RMI".equals(protocol)) { 
throw new MalformedURLException("Invalid URL scheme 
™ + protocol + """); 


} 


/主机 
String host = url.getHost(); 
/端口 
int port = url.getPort(); 
/服务 名 
String name = url.getPath(); 
if Mame != null && name.startsWith("/")) { 
name = name.substring(1); 
} 
Registry registry = LocateRegistry.getRegistry(host, port, 
this.registry 
Client SocketFactory); 
stub = registry.lookup(name); 
} 
else { 
// Can proceed with standard RMI lookup API... 
stub = Naming.lookup(getServiceUrl()); 
} 
if (logger.isDebugEnabled()) { 
logger.debug("Located RMI stub with URL [" + getServiceUrl() 
+"); 
} 
return stub; 
} 
catch (MalformedURLException ex) { 
throw new RemoteLookupFailureException("Service URL [" + 


getServiceUrl() + 


"] is invalid", ex); 
} 
catch (NotBoundException ex) { 
throw new RemoteLookupFailureException( 
"Could not find RMI service [" + getServiceUrl() + "] in RMI 
registry", ex); 
} 
catch (RemoteException ex) { 
throw new RemoteLookupFailureException("Lookup of RMI stub 
failed", ex); 
} 

} 

为 了 使 用 registryClientSocketFactory， 代 码 量 比 使 用 RMI 标 准 获取 
stub 方 法 多 出 了 很 多 ， 那 么 registryClientSocketFactory 到 底 是 做 什么 用 的 
呢 ? 

与 之 前 服务 端的 套 接 字 工 厂 类 似 ， 这 里 的 
registryClientSocketFactory 用 来 连接 RMI 服 务 器 ， 用 户 通 过 实现 
RMIClientSocketFactory 接 口 来 控制 用 于 连接 的 socket 的 各 种 参数 。 

2. 增强 器 进行 远程 连接 

之 前 分 析 了 类 型 为 RMIProxyFactoryBean 的 bean 的 初始 化 中 完成 的 
逻辑 操作 。 在 初始 化 时 ， 创 建 了 代理 并 将 本 身 作 为 增强 器 加 入 了 代理 中 

( RMIProxyFactoryBean 间接 实现 了 MethodInterceptor) 。 那 么 这 样 一 
来 ， 当 在 客户 站 调用 代理 的 接口 中 的 某 个 方法 时 ， 就 会 首先 执行 
RMIProxyFactoryBean 中 的 invoke 方 法 进行 增强 。 

public Object invoke(MethodInvocation invocation) throws Throwable { 

/获取 的 服务 器 中 对 应 的 注册 的 remote 对 象 ， 通 过 序列 化 传输 
Remote stub = getStub(); 





try { 
return doInvoke(invocation, stub); 
j 
catch (RemoteConnectFailureException ex) 1 
return handleRemoteConnectFailure(invocation, ex); 
j 
catch (RemoteException ex) 1 
if (isConnectFailure(ex)) 1 
return handleRemoteConnectFailure(invocation, ex); 
j 
else { 


throw ex; 


} 
众所周知 ， 当 客户 端 使 用 接口 进行 方法 调用 时 是 通过 RMI 获 取 stub 
的 ， 然 后 再 通过 stub 中 封装 的 信息 进行 服务 器 的 调用 ， 这 个 stub 束 是 在 
构建 服务 器 时 发 布 的 对 象 ， 那 么 ， 客 户 闹 调用 时 最 关键 的 一 步 也 是 进行 
stub 的 获取 了 。 
protected Remote getStub() throws RemoteLookupFailureException { 
if (!this.cacheStub || (this.lookupStubOnStartup && 
Ithis.refreshStubOnConnect 
Failure)) 1 
/如 果 有 缓存 直接 使 用 缓存 


return (this.cachedStub != null ? this.cachedStub : lookupStub()); 
} 


else { 


synchronized (this.stubMonitor) { 
if (this.cachedStub == null) { 
/获取 stub 
this.cachedStub = lookupStub(); 
i 


return this.cachedStub; 


} 

当 获 取 到 stub 后 便 可 以 进行 远程 方法 的 调用 了 。Spring 中 对 于 远程 
方法 的 调用 其 实 是 分 两 种 情况 考虑 的 。 

获取 的 stub 是 RMIInvocationHandler 类 型 的 ， 从 服务 端 获 取 的 stub 是 
RMIInvocation Handler， 就 意味 着 服务 端 也 同样 使 用 了 Spring 去 构建 ， 
那么 自然 会 使 用 Spring 中 作 的 约定 ， 进 行 客 己 端 调用 处 理 。Spring 中 的 
处 理 方式 被 委托 给 了 doInvoke 方 法 。 

当 获 取 的 stub 不 是 RMIInvocationHandler 类 型 ， 那 么 服务 端 构建 RMI 
服务 可 能 是 通过 普通 的 方法 或 者 借助 于 Spring 外 的 第 三 方 插件 ， 那 么 处 
理 方 式 自然 会 按照 RMI 中 普通 的 处 理 方式 进行 ， 而 这 种 普通 的 处 理 方 
式 无 非 是 反射 。 因 为 在 invocation 中 包含 了 所 需要 调用 的 方法 的 各 种 信 
奶 ， 包 括 方法 名 称 以 及 参数 等 ， 而 调用 的 实体 正 是 sub， 那 么 通过 反射 
方法 完全 可 以 激活 stub 中 的 远程 调用 。 

protected Object doInvoke(MethodInvocation invocation, Remote stub) 
throws Throwable { 

//stub 从 服务 器 传 回 且 经 过 Spring 的 封装 
if (stub instanceof RMIInvocationHandler) { 
try { 
return doInvoke(invocation, (RMIInvocationHandler) stub); 


} 
catch (RemoteException ex) { 
throw RMIClientInterceptorUtils.convertRMIAccessException( 
invocation.getMethod(), ex, isConnectFailure(ex), 
getServiceUrl()); 
j 
catch (InvocationTargetException ex) { 


Throwable exToThrow = ex.getTargetException(); 


RemoteInvocationUtils.fillInClientStackTracelfPossible(exToThrow); 
throw exToThrow; 
j 
catch (Throwable ex) 1 
throw new RemoteInvocationFailureException(" Invocation of 
method [" + 
invocation.getMethod() + 
"] failed in RMI service [" + getServiceUrl() + "]", ex); 
} 
} 
else { 
try { 
/直接 使 用 反射 方法 继续 激活 
return 
RMIClientInterceptorUtils.invokeRemoteMethod(invocation, stub); 
} 
catch (InvocationTargetException ex) { 


Throwable targetEx = ex.getTargetException(); 


if (targetEx instanceof RemoteException) { 
RemoteException rex = (RemoteException) targetEx; 
throw 

RMIClientInterceptorUtils.convertrRMIA ccessException( 

invocation.getMethod(), rex, isConnectFailure(rex), 
getServiceUrl()); 

j 

else { 


throw targetEx; 


} 

之 前 反复 提 到 了 Spring 中 的 客户 端 处 理 RMI 的 方式 。 其 实 ， 在 分 析 
服务 端 发 布 RMI 的 方式 时 ， 我 们 已 经 了 解 到 ，Spring 将 RMI 的 导出 Object 
封 狼 成 了 RMIInvocationHandler 类 型 进行 发 布 ， 那 么 当 客 户 病 获取 stub 的 
时 候 是 包含 了 远程 连接 信息 代理 类 的 RMIInvocationHandler， 也 就 是 说 
当 调 用 RMIInvocationHandler 中 的 方法 时 会 使 用 RMI 中 提供 的 代理 进行 
远程 连接 ， 而 此 时 ，Spring 中 要 做 的 就 是 将 代码 引 向 
RMIInvocationHandler 接 口 的 invoke 方 法 的 调用 。 


protected Object doInvoke(MethodInvocation methodInvocation, 





RMIInvocationHandler 
invocationHandler) 
throws RemoteException, NoSuchMethodException, 
IllegalAccessException, Invocation 
TargetException { 
if (AopUtils.isToStringMethod(methodInvocation.getMethod())) { 


return "RMI invoker proxy for service URL [" + getServiceUrl() + 


} 

/将 methodInvocation 中 的 方法 名 及 参数 等 信息 重新 封装 到 
RemoteInvocation， 并 通过 远程 代理 

方法 直接 调用 

return 
invocationHandler.invoke(createRemoteInvocation(methodInvocation)); 


} 


12.2 HttpInvoker 


Spring 开发 小 组 意识 到 在 RMI 服 务 和 基于 HITP 的 服务 〈 如 Hessian 
和 Burlap) 之 间 的 空白 。 一 方面 ，RMI 使 用 Java 标 准 的 对 象 序 列 化 ， 但 
很 难 穿越 防火 墙 ， 男 一 方面 ，Hessian/Burlap 能 很 好 地 和 穿 过 防火 墙 工 作 ， 
但 使 用 自己 私有 的 一 套 对 象 序 列 化 机 制 。 

就 这 样 ，Spring 的 HttpInvoker 应 运 而 生 。HttpInvoker 是 一 个 新 的 远 
程 调用 模型 ， 作 为 Spring 框 架 的 一 部 分 ， 来 执行 基于 HTTP 的 远程 调用 
(让 防火 墙 高 兴 的 事 ) ， 并 使 用 Java 的 序列 化 机 制 ( 这 是 让 程序 员 高 兴 
的 事 ) 。 

我 们 首先 看 看 HttpInvoker 的 使 用 示例 。HttpInvoker 是 基于 HITP 的 
远程 调用 ， 同 时 也 是 使 用 Spring 中 提供 的 web 服 务 作 为 基础 ， 所 以 我 们 
的 测试 需要 首先 搭建 Web 工 程 。 


12.2.1 ZN Bl 


(1) 创建 对 外 接口 。 
public interface HttpInvokerTestl { 
public String getTestPo(String desp); 


ES 


TS 


} 
(2) 创建 接口 实现 类 。 
public class HttpInvokertestImpl implements HttpInvokerTestI { 
@Override 
public String getTestPo(String desp) { 


return "getTestPo " + desp; 


} 
(3) 创建 服务 端 配 置 文件 applicationContext-server.xml。 
<?xml version="1.0" encoding="UTF-8"?> 
«beans xmlns="http://www.Springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation=" 
http://www.Springframework.org/schema/beans 


http://www.Springframework.org/schema/beans/Spring-beans-3.0.xsd 


<bean name="httpinvokertest" class-"test.HttpInvokertestImpl" /> 

</beans> 

(4) TEWEB-INF F &iJ£&remote-servlet.xml . 

<?xml version="1.0" encoding="UTF-8"?> 

«beans xmlns="http://www.Springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation=" 

http://www.Springframework.org/schema/beans 


http://www.Springframework.org/schema/beans/Spring-beans-3.0.xsd 


<bean name="/hit" 


class="org.Springframework.remoting.httpinvoker.HttpInvokerServiceExport 
<property name="service" ref-"httpinvokertest" /> 
«property name="servicelnterface" value="test.HttpInvokerTestI" 
/> 
</bean> 
</beans> 
至 此 ， 服 务 端 的 httpInvoker 服务 已 经 搭建 完了 ， 局 动 Web 工程 后 
就 可 以 使 用 我 们 搭建 的 HttpInvoker 服 务 了 。 以 上 代码 实现 了 将 远程 传 入 
的 字符 串 参数 处 理 加 入 “getTestPo” 前 级 的 功能 。 服 务 端 搭建 完 基于 Web 
服务 的 HttpInvoker 后 ， 客 户 端 还 需要 使 用 一 定 的 配置 才能 进行 远程 调 
用 。 





(5) 创建 测试 端 配 置 client.xml。 
<?xml version="1.0" encoding="UTF-8"?> 
«beans xmlIns="http://www.Springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation=" 
http://www.Springframework.org/schema/beans 
http://www.Springframework.org/schema/beans/Spring-beans-3.0.xsd 
"> 


<bean id="remoteService" 


class="org.Springframework.remoting.httpinvoker.HttpInvokerProxyFactoryE 
<property name="serviceUrl" 
value="http://localhost:8080/httpinvokertest/ 
remoting/hit" /> 


«property name="servicelnterface" value="test.HttpInvokerTestI" 


</bean> 
</beans> 
(6) 创建 测试 类 。 
public class Test { 
public static void main(String[] args) { 
ApplicationContext context = new 
ClassPathXmlApplicationContext ("classpath: 
client.xml"); 
HttpInvokerTestI httpInvokerTestI = (HttpInvokerTestI) 
context.getBean 
("remoteService"); 


System.out.printIn(httpInvokerTestI.get l'estPo("dddd")); 


j 

运行 测试 类 ， 你 会 看 到 打印 结 

getTestPo dddd 

dddd 是 我 们 传 入 的 参数 ， 而 getTestPo 则 是 在 服务 端 添 加 的 字符 串 。 
当然 ， 上 面 的 服务 拱 建 与 测试 过 程 中 都 是 在 一 台 机 器 上 进行 的 ， 如 果 需 
要 在 不 同 机 器 上 进行 测试 ， 还 需要 读者 对 服务 端的 相关 接口 打 成 JAR 包 
并 加 入 到 客户 端的 服务 器 上 。 

12.2.2 服务 端 实现 

对 于 Spring 中 HttpInvoker 服 务 的 实现 ， 我 们 还 是 首先 从 服务 端 进行 
分 析 。 

根据 remote-servlet.xml 中 的 配置 ， 我 们 分 析 入 口 类 应 该 为 


org.Springframework.remoting.httpinvoker. HttpInvokerServiceExporter, 





那么 同样 ， 根 据 这 个 类 分 析 其 入 口 函 数 ， 如 网 12-3 所 示 。 
‘t 31) 1 M 
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图 12-3 HttpInvokerServiceExporter 类 的 层次 结构 图 


通过 层次 关系 我 们 看 到 HttpInvokerService Exporter 类 实现 了 

InitializingBean 接口 以 及 Http RequestHandler 接 口 。 分 析 RMI 服 务 时 我 
们 已 经 了 解 到 了 ， 当 某 个 bean 继 承 自 InitializingBean 接 口 的 时 候 ， 
Spring 会 确保 这 个 bean 在 初始 化 时 调用 其 afterPropertiesSet 方法 ， 而 对 
于 HttpRequestHandler 接 口 ， 因 为 我 们 在 配置 中 已 经 将 此 接口 配置 成 Web 
服务 ， 那 么 当 有 相应 请 求 的 时 候 ，Spring 的 Web 服 务 就 会 将 程序 引导 至 
HttpRequestHandler 的 handleRequest 方 法 中 。 首 先 ， 我 们 从 
afterPropertiesSet 方 法 开始 分 析 ， 看 看 在 bean 的 初始 化 过 程 中 做 了 哪些 多 
辑 。 

1. 创建 代理 

public void afterPropertiesSet() { 

prepare(); 
} 
public void prepare() { 
this.proxy = getProxyForService(); 


} 
protected Object getProxyForService() { 
/验证 service 
checkService(); 
/验证 serviceInterface 
checkServiceInterface(); 
/使 用 JDK 的 方式 创建 代理 
ProxyFactory proxyFactory = new ProxyFactory(); 
YS VA Ee A 
proxyFactory.addInterface(getServiceInterface()); 
if (this.registerTraceInterceptor != null ? 
this.registerTraceInterceptor.booleanValue() : this.interceptors == 
null) { 
/加 入 代理 的 横 切 面 RemoteInvocationTraceInterceptor 并 记录 
Exporter fj 
proxyFactory.addAdvice(new RemoteInvocationTraceInterceptor 
(getExporterName())); 
} 
if (this.interceptors != null) { 
AdvisorAdapterRegistry adapterRegistry = 
GlobalAdvisorAdapterRegistry. 
getInstance(); 


for (int i = 0; i < this.interceptors.length; i++) { 


proxyFactory.addAdvisor(adapterRegistry.wrap(this.interceptors|i])); 
} 


/设置 要 代理 的 目标 类 
proxyFactory.setTarget(getService()); 
proxyFactory.setOpaque(true); 
/创建 代理 
return proxyFactory.getProxy(getBeanClassLoader()); 
} 
通过 将 上 面 3 个 方法 串联 ， 可 以 看 到 ， 初 始 化 过 程 中 实现 的 逻辑 主 
要 是 创建 了 一 个 代理 ， 代 理 中 封装 了 对 于 特定 请 求 的 处 理 方法 以 及 接口 
等 信息 ， 而 这 个 代理 的 最 关键 目的 是 加 入 了 
Li EH quM d 强 器 ， 当 然 创 建 代 理 还 有 些 其 他 好 
处 ， 比 如 代码 优雅 、 方 便 扩 展 等 。RemoteInvocationTraceInterceptor 中 
的 增强 主要 是 对 增强 的 目标 方法 进行 一 些 相关 信息 的 日 志 打 印 ， 并 没有 
在 此 基础 上 进行 任何 功能 性 的 增强 。 那 么 这 个 代理 究竟 是 在 什么 时 候 使 
用 的 呢 ? 暂时 留 下 悬念 ， 我 们 接 下 来 分 析 当 有 Web 请 求 时 
HttpRequestHandler 的 handleRequest 方 法 的 处 理 。 
2. 处 理 来 自 客户 端的 request 
当 有 Web 请 求 时 ， 根 据 配 置 中 的 规则 会 把 路 径 匹 配 的 访问 直接 引 
入 对 应 的 HttpRequest Handler 中 。 本 例 中 的 Web 请 求 与 普通 的 Web 请 
求 是 有 些 区 别 的 ， 因 为 此 处 的 请 求 包含 着 HttpInvoker 的 处 理 过 程 。 
public void handleRequest(HttpServletRequest request, 
HttpServletResponse response) 
throws ServletException, IOException { 
try { 
/从 request 中 读 取 序列 化 对 象 
RemoteInvocation invocation = readRemoteInvocation(request); 
/执行 调用 


RemoteInvocationResult result = 


invokeAndCreateResult(invocation, getProxy()); 
IEEE ER FP AS BAS NA En i 
writeRemoteInvocationResult(request, response, result); 
j 
catch (ClassNotFoundException ex) 1 
throw new NestedServletException(" Class not found during 
deserialization", ex); 
j 
j 
在 handlerRequest 函 数 中 ， 我 们 很 清楚 地 看 到 了 HttpInvoker 处 理 的 大 
致 框架 ，HttpInvoker 服 务 简 单 点 说 就 是 将 请 求 的 方法 ， 也 就 是 
RemoteInvocation 对 象 ， 从 客户 端 序列 化 并 通过 Web 请 求 出 入 服务 端 ， 
服务 端 在 对 传 过 来 的 序列 化 对 象 进行 反 序 列 化 还 原 RemoteInvocation 实 
例 ， 然 后 通过 实例 中 的 相关 信息 进行 相关 方法 的 调用 ， 并 将 执行 结果 再 
次 的 返回 给 客户 端 。 从 handleRequest 函 数 中 我 们 也 可 以 清晰 地 看 到 程序 
执行 的 框架 结构 。 
(1) 从 request 中 读 取 序列 化 对 象 。 
主要 是 从 HttpServletRequest 提取 相关 的 信息 ， 也 就 是 提取 
HttpServletRequest 中 的 RemoteInvocation 对 象 的 序列 化 信息 以 及 反 序 列 
化 的 过 程 。 


protected RemoteInvocation readRemoteInvocation(HttpServletRequest 








request) 
throws IOException, ClassNotFoundException 1 
return readRemoteInvocation(request, request.getInputStream()); 
j 
protected RemoteInvocation readRemoteInvocation(HttpServletRequest 


request, InputStream is) 


throws IOException, ClassNotFoundException { 
IL) EY 46] AN f 
ObjectInputStream ois = 
createObjectInputStream(decorateInputStream(request, is)); 
try 1 
/从 输入 流 中 读 取 序列 化 对 象 
return doReadRemoteInvocation(ois); 
} 
finally { 


ois.close(); 


} 

protected RemoteInvocation 
doReadRemoteInvocation(ObjectInputStream ois) 

throws IOException, ClassNotFoundException 1 

Object obj 7 ois.readObject(); 
if (!(obj instanceof RemoteInvocation)) 1 
throw new RemoteException("Deserialized object needs to be 
assignable to type [" + 
RemoteInvocation.class.getName() + "]: " + obj); 
} 
return (RemoteInvocation) obj; 

} 

对 于 序列 化 提取 与 转换 过 程 其 实 并 没有 太 多 需要 解释 的 东西 ， 这 里 
完全 是 按照 标准 的 方式 进行 操作 ， 包 括 创 建 ObjectInputStream 以 及 从 
ObjectInputStream 中 提取 对 象 实 例 。 

(2) 执行 调用 。 








根据 反 序 列 化 方式 得 到 的 RemoteInvocation 对 象 中 的 信息 ， 进 行 方 
法 调用 。 注 意 ， 此 时 调用 的 实体 并 不 是 服务 接口 或 者 服务 类 ， 而 是 之 前 
在 初始 化 时 候 构 造 的 封装 了 服务 接口 以 及 服务 类 的 代理 。 
完成 了 RemoteInvocation 实 例 的 提取 ， 也 就 意味 着 可 以 通过 
RemoteInvocation 实 例 中 提供 的 信息 进行 方法 调用 了 。 
protected RemoteInvocationResult 
invokeAndCreateResult(RemoteInvocation invocation, 
Object targetObject) { 
try { 
/激活 代理 类 中 对 应 invocation 中 的 方法 
Object value = invoke(invocation, targetObject); 
/封装 结果 以 便于 序列 化 
return new RemoteInvocationResult(value); 
j 
catch (Throwable ex) 1 


return new RemoteInvocationResult(ex); 


} 

这 段 函 数 有 两 点 需要 说 明 的 地 方 。 

对 应 方法 的 激活 也 就 是 invoke 方 法 的 调用 ， 虽 然 经 过 层 层 环绕 ， 但 
是 最 终 还 是 实现 了 一 个 我 们 熟知 的 调用 invocation.invoke(targetObject)， 
也 就 是 执行 RemoteInvocation 类 中 的 invoke 方法 ， 大 致 的 逻辑 还 是 通过 
RemoteInvocation 中 对 应 的 方法 信息 在 targetObject 上 去 执行 ， 此 方法 在 
分 析 RMI 功能 的 时 候 已 经 分 析 过 ， 不 再 痪 述 。 但 是 在 对 于 当前 方法 的 
targetObject 参 数 ， 此 targetObject 是 代理 类 ， 调 用 代理 类 的 时 候 需 要 考虑 
增强 方法 的 调用 ， 这 是 读者 需要 注意 的 地 方 。 

对 于 返回 结果 需要 使 用 RemoteInvocationResult 进行 封装 ， 之 所 以 











需要 通过 使 用 RemoteInvocationResult 类 进行 封闭， 是 因为 无 法 保证 对 于 
所 有 操作 的 返回 结果 都 继承 Serializable 接 口 ， 也 就 是 说 无 法 保证 所 有 返 
回 结果 都 可 以 直接 进行 序列 化 ， 那 么 ， 就 必须 使 用 
RemoteInvocationResult 类 进行 统一 封装 。 

(3) 将 结果 的 序列 化 对 象 写 入 输出 流 。 

同样 这 里 也 包括 结果 的 序列 化 过 程 。 


protected void writeRemoteInvocationResult( 








HttpServletRequest request, HttpServletResponse response, 
RemoteInvocation 
Result result) throws IOException { 
response.setContentType(getContentT ype()); 
writeRemoteInvocationResult(request, response, result, 
response.getOutputStream()); 
j 
protected void writeRemoteInvocationResult( 
HttpServletRequest request, HttpServletResponse response, 
RemoteInvocation 
Result result, OutputStream os) 
throws IOException 1 
/获取 输入 流 
ObjectOutputStream oos = 
createObjectOutputStream(decorateOutputStream(request, 
response, 0s)); 
try { 
/将 序列 化 对 象 写 入 输入 流 


doWriteRemoteInvocationResult(result, oos); 


finally { 


oos.close(); 


} 

protected void 
doWriteRemoteInvocationResult(RemoteInvocationResult result, 
ObjectOutput 

Stream oos)throws IOException 1 


oos.writeObject(result); 





分 析 了 服务 端的 解析 以 及 处 理 过 程 后 ， 我 们 接 下 来 分 析 客 户 端的 调 
用 过 程 ， 在 服务 端 调 用 的 分 析 中 我 们 反复 提 到 需要 从 HttpServletRequest 
中 提取 从 客户 端 传 来 的 RemoteInvocation 实例 ， 然 后 进行 相应 解析 。 所 
以 ， 在 客户 端 ， 一 个 比较 重要 的 任务 就 是 构建 RemoteInvocation 实 例 ， 
并 传送 到 服务 端 。 根 据 配置 文件 中 的 信息 ， 我 们 还 是 首先 锁定 
HttpInvokerProxyFactoryBean 类 ， 并 查看 其 层次 结构 ， 如 图 12-4 所 示 。 

从 层次 结构 中 我 们 看 到 ，HttpInvokerProxyFactoryBean 类 同样 实现 
AAE E E 同时 ， 又 实现 了 FactoryBean 以 及 
MethodInterceptor。 这 已 经 是 老生 常 谈 的 问题 了 7， 实现 这 几 个 接口 以 及 
这 几 个 接口 在 Spring 中 会 有 什么 作用 就 不 再 次 述 了 ， 我 们 还 是 根据 实现 
的 PnitializingBean 接 口 分 析 初 始 化 过 程 中 的 逻辑 。 
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图 12-4 HttpInvokerProxyFactoryBean 类 的 层次 结构 图 


public void afterPropertiesSet() { 
super.afterPropertiesSet(); 
if (getServiceInterface() == null) { 
throw new IllegalArgumentException("Property 'serviceInterface' 
is 
required"); 
} 
/创建 代理 并 使 用 当前 方法 为 拦截 器 增强 
this.serviceProxy = new ProxyFactory(getServicelnterface(), 
this).getProxy 
(getBeanClassLoader()); 


} 
在 afterPropertiesSet 中 主要 创建 了 一 个 代理 ， 该 代理 封装 了 配置 的 服 


务 接口 ， 并 使 用 当前 类 也 就 是 HttpInvokerProxyFactoryBean 作为 增强 。 
为 HttpInvokerProxyFactoryBean 实现 了 MethodInterceptor 方 法 ， 所 以 
可 以 作为 增强 拦截 器 。 

同样 ， 又 由 于 HttpInvokerProxyFactoryBean 实 现 了 FactoryBean 接 
口 ， 所 以 通过 Spring 中 普通 方式 调用 该 bean 时 调用 的 并 不 是 该 bean 本 
号 ， 而 是 此 类 中 getObject 方 法 返回 的 实例 ， 也 丈 是 实例 化 过 程 中 所 创建 
的 代理 。 

public Object getObject() 1 





return this.serviceProxy; 

j 

那么 ， 综 合 之 前 的 使 用 示例 ， 我 们 再 次 回顾 一 下 ， 
HttpInvokerProxyFactoryBean 类 型 bean 在 初始 化 过 程 中 创建 了 封装 服务 
接口 的 代理 ， 并 使 用 自 喘 作为 增强 拦截 器 ， 然 后 又 因为 实现 了 
FactoryBean 接 口 ， 所 以 获取 Bean 的 时 候 返 回 的 其 实 是 创建 的 代理 。 那 
么 ， 汇 总 上 面 的 逻辑 ， 当 调用 如 下 代码 时 ， 其 实 是 调用 代理 类 中 的 服务 
方法 ， 而 在 调用 代理 类 中 的 服务 方法 时 又 会 使 用 代理 类 中 加 入 的 增强 器 
进行 增强 。 

ApplicationContext context = new 
ClassPathXmlApplicationContext("classpath:client.xml"); 

HttpInvokerTestI httpInvokerTestI = (HttpInvokerTestI) 
context.getBean("remoteService"); 

System.out.printIn(httpInvokerTestI.get l'estPo("dddd")); 

这 时 ， 所 有 的 逻辑 分 析 其 实 已 经 被 转向 了 对 于 增强 器 也 就 是 
HttpInvokerProxyFactoryBean 类 本 身 的 invoke 方 法 的 分 析 。 

在 分 析 invoke 方 法 之 前 ， 其 实 我 们 已 经 猜 出 了 该 方法 所 提供 的 主要 
功能 就 是 将 调用 信息 封装 在 RemoteInvocation 中 ， 发 送 给 服务 端 并 等 待 
返回 结果 。 


public Object invoke(MethodInvocation methodInvocation) throws 
Throwable { 
if (AopUtils.isToStringMethod(methodInvocation.getMethod())) { 
return "HTTP invoker proxy for service URL [" + getServiceUrl() 


/将 要 调用 的 方法 封装 为 RemoteInvocation 
RemoteInvocation invocation = 
createRemoteInvocation(methodInvocation); 


RemoteInvocationResult result = null; 


try 1 

/远程 执行 方法 

result = executeRequest(invocation, methodInvocation); 
} 


catch (Throwable ex) { 
throw convertHttpInvokerAccessException(ex); 
} 
try { 
/提取 结果 
return recreateRemoteInvocationResult(result); 
j 
catch (Throwable ex) 1 
if (result.hasInvocationTargetException()) 1 
throw ex; 
j 
else { 
throw new RemoteInvocationFailureException(" Invocation of 


method [" + 
methodInvocation.getMethod() + 
"] failed in HTTP invoker remote service at [" + getServiceUrl() 


十 aa ee ex); 


} 
函数 主要 有 3 个 步骤。 
(1) 构建 RemoteInvocation 实 例 。 
因为 是 代理 中 增强 方法 的 调用 ， 调 用 的 方法 及 参数 信息 会 在 代理 中 
封装 至 MethodInvocation 实 例 中 ， 并 在 增强 方 嚣 中 进行 传递 ， 也 就 意味 
着 当 程 序 进 入 invoke 方 法 时 其 实 是 已 经 包含 了 调用 的 接口 的 相关 信息 
的 ， 那 么 ， 首 先 要 做 的 就 是 将 MethodInvocation 中 的 信息 提取 并 构建 
RemoteInvocation 实 例 。 
(2) 远程 执行 方法 。 
(3) 提取 结 
考虑 到 序列 化 的 问题 ， 在 Spring 中 约定 使 用 HttpInvoker 方 式 进行 远 
程 方法 调用 时 ， 结 果 使 用 RemoteInvocationResult 进行 封装 ， 那 么 在 提 
取 结 果 后 还 需要 从 封装 的 结果 中 提取 对 应 的 结果 。 
而 在 这 三 个 步骤 中 最 为 关键 的 就 是 远程 方法 的 执行 。 执 行 远 程 调用 
的 首要 步骤 就 是 将 调用 方法 的 实例 与 入 输出 流 中 。 


protected RemoteInvocationResult executeRequest( 








RemoteInvocation invocation, MethodInvocation originalInvocation) 
throws Exception 1 
return executeRequest(invocation); 


} 


protected RemoteInvocationResult executeRequest(RemoteInvocation 


invocation) throws Exception { 
return getHttpInvokerRequestExecutor().executeRequest(this, 
invocation); 
} 
public final RemoteInvocationResult executeRequest( 
HttpInvokerClientConfiguration config, RemoteInvocation invocation) 
throws 
Exception { 
/获取 输出 流 
ByteArrayOutputStream baos = 
getByteArrayOutputStream(invocation); 
if (logger.isDebugEnabled()) { 
logger.debug(" Sending HTTP invoker request for service at [" + 


config.getServiceUrl() + 
"], with size "  baos.size()); 


j 
return doExecuteRequest(config, baos); 
j 
在 doExecuteRequest 方 法 中 真正 实现 了 对 远程 方法 的 构造 与 通信 ， 
与 远程 方法 的 连接 功能 实现 中 ，Spring 引 入 了 第 三 方 JAR: HttpClient。 
HttpClient 是 Apache Jakarta Common 下 的 子 项 目 ， 可 以 用 来 提供 高 交 
的 、 最 新 的 、 功 能 丰富 的 支持 HTTP 协 议 的 客户 端 编程 工具 包 ， 并 且 它 
文 持 HTTP 协 议 最 新 的 版 本 和 建议 。 对 HttpClient 的 具体 使 用 方法 有 兴趣 
的 读者 可 以 参考 更 多 的 资料 和 文档 。 


protected RemoteInvocationResult doExecuteRequest( 











HttpInvokerClientConfiguration config, ByteArrayOutputStream baos) 
throws IOException, ClassNotFoundException { 
/创建 HttpPost 
HttpPost postMethod = createHttpPost(config); 
/设置 含有 方法 的 输出 流 到 post 中 
setRequestBody(config, postMethod, baos); 
try { 
/执行 方法 并 等 待 结果 啊 应 
HttpResponse response = executeHttpPost(config, getHttpClient(), 
postMethod); 
/验证 
validateResponse(config, response); 
/提取 返 回 的 输入 流 
InputStream responseBody = getResponseBody(config, response); 
/从 输入 流 中 提取 结 
return readRemoteInvocationResult(responseBody, 
config.getCodebaseUrl()); 
} 
finally { 
if (releaseConnectionMethod != null){ 
ReflectionUtils.invokeMethod(releaseConnectionMethod, 
postMethod); 
} 


} 
Bi BREN BAZE A Dr P m SM EE o 
1. 创建 HttpPost 





由 于 对 于 服务 端 方法 的 调用 是 通过 Post 方 式 进行 的 ， 那 么 首先 要 做 
的 就 是 构建 HttpPost， 构 建 HttpPost 过 程 中 可 以 设置 一 些 必 要 的 参数 。 
protected PostMethod 
createPostMethod(HttpInvokerClientConfiguration config) throws 
IOException { 
/设置 需要 访问 的 ul 
PostMethod postMethod = new PostMethod(config.getServiceUrl()); 
LocaleContext locale = LocaleContextHolder.getLocaleContext(); 
if (locale != null) { 
/加 入 Accept-Language 属 性 


postMethod.addRequestHeader(HTTP_HEADER_ACCEPT_LANGUAGE, 
StringUtils. 
toLanguageTag(locale.getLocale())); 
} 
if (isAcceptGzipEncoding() { 
/加 入 Accept-Encoding 属 性 


postMethod.addRequestHeader(HTTP_HEADER_ACCEPT_ENCODING, 
ENCODING_GZIP); 
} 
return postMethod; 
} 
2. 设置 RequestBody 
构建 好 PostMethod 实 例 后 便 可 以 将 存储 RemoteInvocation 实 例 的 序 
列 化 对 象 的 输出 流 设置 进去 ， 当 然 这 里 需要 注意 的 是 传 入 的 
ContentType 类 型 ， 一 定 要 传 入 application/x-java-serialized-object 以 保证 





服务 端 解析 时 会 按照 序列 化 对 象 的 解析 方式 进行 解析 。 
protected void setRequestBody( 
HttpInvokerClientConfiguration config, PostMethod postMethod, 
ByteArrayOutputStream 
baos) 
throws IOException 1 
/将 序列 化 流 加 入 到 postMethod 中 并 声明 ContentType 类 型 为 
application/x-java-serialized-object 
postMethod.setRequestEntity(new 
ByteArrayRequestEntity(baos.toByteArray(), 
getContentType())); 
} 
3. 执行 远程 方法 
通过 HttpClient 所 提供 的 方法 来 直接 执行 远程 方法 。 
protected void executePostMethod( 





HttpInvokerClientConfiguration config, HttpClient httpClient, 
PostMethod 
postMethod) throws IOException { 
httpClient.executeMethod(postMethod); 
} 
4. 远程 相应 验证 
对 于 HTTP 调 用 的 啊 应 码 处 理 ， 大 于 300 则 是 非 正常 调用 的 响应 码 。 


protected void validateResponse(HttpInvokerClientConfiguration 








config, PostMethod 
postMethod) 
throws IOException { 
if (postMethod.getStatusCode() >= 300) { 


throw new HttpException( 
"Did not receive successful HTTP response: status code = " + 


postMethod.getStatusCode() + 
", status message = [" + postMethod.getStatusText() + "]"); 


} 

5. 提取 啊 应 信息 

从 服务 器 返回 的 输入 流 可 能 是 经 过 压缩 的 ， 不 同 的 方式 采用 不 同 的 
办 法 进行 提前 。 

protected InputStream 
getResponseBody(HttpInvokerClientConfiguration config, PostMethod 

postMethod) 

throws IOException { 

if (isGzipResponse(postMethod)) { 





return new 


GZIPInputStream(postMethod.getResponseBodyAsStream()); 
j 


else 1 
return postMethod.getResponseBodyAsStream(); 


j 

6. 提取 返回 结果 

提取 结果 的 流程 主要 是 从 输入 流 中 提取 啊 应 的 序列 化 信和 号。 
protected RemoteInvocationResult 


readRemoteInvocationResult(InputStream is, String 


codebaseUrl) 

throws IOException, ClassNotFoundException { 
ObjectInputStream ois = 

createObjectInputStream(decorateInputStream(is), 
codebaseUrl); 
try { 
return doReadRemoteInvocationResult(ois); 

} 
finally { 


ois.close(); 


第 13 音 ”Spring 消息 


Java 消 息 服务 (Java Message Service, JMS) 应 用 程序 接口 是 一 个 
Java 平 台中 关于 面向 消息 中 间 件 (MOM) 的 API， 用 于 在 两 个 应 用 程序 
之 间或 分 布 式 系统 中 发 送 消息 ， 进 行 异 步 通信 。Java 消 息 服 务 是 一 个 与 
具体 平台 无 关 的 API， 绝 大 多 数 MOM 提 供 商 都 对 JMS 提 供 支 持 。 

Java 消 息 服 务 的 规范 包括 两 种 消息 模式 ， 点 对 点 和 发 布 者 /订阅 者 。 
许多 提供 了 商 支持 这 一 通用 框架 。 因 此 ， 程 序 员 可 以 在 他 们 的 分 布 式 软件 
中 实现 面向 消息 的 操作 ， 这 些 操作 将 具有 不 同 面 癌 消息 中 间 件 产品 的 可 
移植 性 。 

Java 消 息 服 务 文 持 同步 和 异步 的 消息 处 理 ， 在 某 些 场景 下 ， 肛 步 消 
恩 是 必要 的 ， 而 且 比 同步 消息 操作 更 加 便利 。 

Java 消 息 服 务 文 持 面 同事 件 的 方法 接收 消息 ， 事 件 驱 动 的 程序 设计 
现在 被 广泛 认为 是 一 种 富有 成 效 的 程序 设计 范例 ， 程 序 员 们 都 相当 熟 








在 应 用 系统 开发 时 ，Java 消 恩 服务 可 以 推迟 选择 面 对 消 息 中 间 件 产 
du, tup DAE IBS OSEE A HP RITE HS 
本 章 以 Java 消 息 服 务 的 开源 实现 产品 ActiveMQ 为 例 来 进行 Spring 整 
合 消息 服务 功能 的 实现 分 析 。 


13.1 JMS 的 独立 使 用 


尽管 大 多 数 的 Java 消 息 服 务 的 使 用 都 会 跟 Spring 相 结合 ， 但 是 ， 我 
们 还 是 非常 有 必要 了 解 消息 的 独立 使 用 方法 ， 这 对 于 我 们 了 解 消息 的 实 
现 原理 以 及 后 续 的 与 Spring 整合 实现 分 析 都 非常 重要 。 当 然 在 消息 服务 
的 使 用 前 ， 需 要 我 们 先 开 局 消息 服务 器 ， 如 果 是 Windows 系 统 下 可 以 直 
接 双击 ActiveMQ 安 装 目录 下 的 bin 目 录 下 的 activemdq.bat 文 件 来 启动 消息 
服务 器 。 

消息 服务 的 使 用 除了 要 开局 消息 服务 器 外 ， 还 需要 构建 消息 的 有 友 送 
问 与 接收 端 ， 发 送 端 主要 用 来 将 包含 业务 逻辑 的 消息 发 送 至 消息 服务 
器 ， 而 消息 接收 问 则 用 于 将 服务 器 中 的 消息 提取 并 进行 相应 的 处 理 。 

(1) 发 送 端 实 现 

发 送 端 主要 用 于 发 送 消息 到 消息 服务 器 ， 以 下 为 发 送 消息 测试 ， 洽 

试 发 送 三 条 消息 到 消息 服务 器 ， 消 息 的 内 容 为 “大 家 好 这 是 个 测试 ”。 


public class Sender { 








public static void main(String[] args) throws Exception { 
ConnectionFactory connectionFactory = new 
ActiveMQConnectionFactory(); 
Connection connection = connectionFactory.createConnection(); 
//connection.start(); 


Session session = connection.createSession(Boolean. TRUE, 


Session.AUTO_ACKNOWLEDGE); 
Destination destination = session.createQueue("My-queue"); 
MessageProducer producer = session.createProducer(destination); 
for (int i = 0; i < 3; i++) { 

TextMessage message = session.createTextMessage("A AU 3X 

是 个 测试 "); 

Thread.sleep(1000); 

/通过 消息 生产 者 发 出 消息 

producer.send(message); 


} 


session.commit(); 





session.close(); 


connection.close(); 


} 

上 面 的 函数 实现 很 容易 让 我 们 联想 到 数据 库 的 实现 ， 在 函数 开始 时 
需要 一 系列 风 余 的 但 又 必 不 可 少 的 用 于 连接 的 代码 ， 而 其 中 真正 用 于 发 
送 消息 的 代码 其 实 很 简单 。 

(20 接收 端 实现 。 

接收 端 主要 用 于 连接 消息 服务 器 并 接收 服务 磺 上 的 消息 。 

public class Receiver { 


public static void main(String[] args) throws Exception { 





ConnectionFactory connectionFactory = new 


ActiveMQConnectionFactory(); 
Connection connection = connectionFactory.createConnection(); 


connection.start(); 
final Session session = connection.createSession(Boolean. TRUE, 


Session. AUTO _ 
ACKNOWLEDGE); 
Destination destination = session.createQueue(" my-queue"); 
MessageConsumer consumer = 
session.createConsumer(destination); 
int i=0; 
while(i<3) 1 
i++; 
TextMessage message = (TextMessage) consumer.receive(); 
session.commit(); 
//TODO something.... 
System.out.println(" 收 到 消息 : " + message.getText()); 
} 
session.close(); 


connection.close(); 


} 
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13.2 Spring 4 ActiveMQ 


整个 消息 的 发 送 与 接收 过 程 非常 简单 ， 但 是 其 中 却 参 杂 着 大 量 的 元 
余人 代码， 比如 Connection 的 创建 与 关闭 ，S$ession 的 创建 与 关闭 等 ， 为 了 
消除 这 一 见 余 工作 量 ，Spring 进 行 了 进一步 的 封装 。Spring 下 的 
ActiveMQ 使 用 方式 如 下 。 

(1) Spring 配 置 文件 。 





配置 文件 是 Spring 的 核心 ，Spring 整合 消息 服务 的 使 用 也 从 配置 文 
件 配 置 开 始 。 类 似 于 数据 库 操 作 ，Spring 也 将 ActiveMQ 中 的 操作 统一 封 
装 至 JmsTemplate 中 ， 以 方便 我 们 统一 使 用 。 所 以 ， 在 Spring 的 核心 配 
置 文件 中 首先 要 注册 JmsTemplate 类 型 的 bean. 4%, 
ActiveMQConnection Factory 用 于 连接 消 姑 服务器， 是 消息 服务 的 基 
础 ， 也 要 注册 。ActiveMQQueue 则 用 于 指定 消息 的 目的 地 。 


<beans> 














<bean id="connectionFactory" 
class="org.apache.activemq.ActiveMQConnectionFactory"> 
<property name="brokerURL"> 
<value>tcp://localhost:61616</value> 
</property> 
</bean> 
<bean id="jmsTemplate" 
class="org.Springframework.jms.core.JmsTemplate"> 
<property name="connectionFactory''> 
«ref bean-"connectionFactory" /> 
</property> 
</bean> 
<bean id="destination" 
class="org.apache.activemgq.command.ActiveMQQueue"> 
<constructor-arg index="0"> 
<value>HelloWorldQueue</value> 
</constructor-arg> 
</bean> 
</beans> 


(2) RIŽ Ùi o 


有 了 以 上 的 配置 ，Spring 束 可 以 根据 配置 信息 简化 我 们 的 工作 量 。 
Spring 中 使 用 发 送 消 息 到 消息 服务 器 ， 省 去 了 se E 
Session 等 的 创建 与 销毁 过 程 ， 简 化 了 工作 量 。 

public class HelloWorldSender { 


public static void main(String args[]) throws Exception { 





ApplicationContext context = new 
ClassPathXmlApplicationContext( 

new String[] { "test/activeMQ/Spring/applicationContext.xml" }); 

JmsTemplate jmsTemplate = (JmsTemplate) 
context.getBean("jmsTemplate"); 

Destination destination = (Destination) 
context.getBean(" destination"); 

jmsTemplate.send(destination, new MessageCreator() 1 

public Message createMessage(Session session) throws 
JMSException 1 
return session.createTextMessage(" 大 家 好 这 个 是 测试 ! 7); 


D; 


(3) 接收 端 。 
同样 ， 在 Spring 中 接收 消息 也 非 党 方便，Spring 中 连接 服务 圳 接收 
消息 的 示例 如 下 : 
public class HelloWorldReciver { 
public static void main(String args[]) throws Exception { 
ApplicationContext context = new 


ClassPathXmlApplicationContext( 


new String[] { "test/activeMQ/Spring/applicationContext.xml" }); 

JmsTemplate jmsTemplate = (JmsTemplate) 
context.getBean("jmsTemplate"); 

Destination destination = (Destination) 
context.getBean(" destination"); 

TextMessage msg - (TextMessage) 
jmsTemplate.receive(destination); 


System.out.println("reviced msg is:"  msg.getText()); 


j 
到 这 里 我 们 已 经 完成 了 Spring 消息 的 发 送 与 接收 操作 。 但 是 ， 如 
HelloWorldReciver 中 所 示 的 代码 ， 使 用 jmsTemplate.receive(destination) 
方法 只 能 接收 一 次 消 晨 ， 如 果 未 接收 到 消息 ， 则 会 一 直 等 每 ， 当 然 用 户 
可 以 通过 设置 timeout 属性 来 控制 等 每 时 间 ， 但 是 一 旦 接收 到 消 恩 本 次 
接收 任务 融会 结束 ， 虽 然 用 户 可 以 通过 while(true) 的 方式 来 实现 循环 监 
听 消 息 服 务 器 上 的 消息 ， 还 有 一 种 更 好 的 解决 办 法 : 创建 消息 监听 器 。 
消 妃 监听 器 的 使 用 方式 如 下 。 
C1) GE THE ILS Ur e 
用 于 监听 消息 ， 一 旦 有 新 消息 Spring 会 将 消息 引导 至 消息 监听 器 以 
方便 用 户 进行 相应 的 逻辑 处 理 。 
public class MyMessageListener implements MessageListener{ 
@Override 
public void onMessage(Message arg0) { 





TextMessage msg = (TextMessage) arg0; 
try { 

System.out.printIn(msg.getText()); 
} catch (JMSException e) { 


e.printStackTrace(); 


} 
(2) 修改 配置 文件 。 


为 了 使 用 消 轧 监听 上 器， 需要 在 配置 文件 中 注册 消息 容 右 ， 


监 昕 器 注入 到 容器 中 。 
<beans> 
<bean id="connectionFactory" 
class="org.apache.activemq.ActiveMQConnectionFactory"> 
<property name="brokerURL"> 
<value>tcp://localhost:61616</value> 
</property> 
</bean> 
<bean id="jmsTemplate" 
class="org.Springframework.jms.core.JmsTemplate"> 
<property name="connectionFactory"> 
«ref bean="connectionFactory" /> 
</property> 
</bean> 
<bean id="destination" 
class="org.apache.activemgq.command.ActiveMQQueue"> 
<constructor-arg index="0"> 
<value>HelloWorldQueue</value> 
</constructor-arg> 
</bean> 


<bean id="myTextListener" 


class="test.activeMQ.Spring.MyMessageListener" /> 


<bean id="javaConsumer" 


class="org.Springframework.jms.listener. DefaultMessageListenerContainer'> 
<property name="connectionFactory" ref="connectionFactory" /> 
<property name="destination" ref="destination" /> 
<property name-"messageL istener" ref-"myTextListener" /> 
</bean> 
</beans> 
通过 以 上 的 修改 便 可 以 进行 消息 监听 的 功能 了 ， 一 旦 有 消息 传 入 至 
消 妃 服务 器 ， 则 会 被 消息 监听 器 监 听 到 ， 并 由 Spring 将 消 恩 内 容 引 导 有 至 
消息 监听 露 的 处 理 函 数 中 等 竺 用户 的 进一步 逻辑 处 理 。 


13.3 源码 分 析 


尽管 消息 接收 可 以 使 用 消息 监听 器 的 方式 蔡 代 模版 方法 ， 但 是 在 发 
送 的 时 候 是 无 法 蔡 代 的 ， 在 Spring 中 必须 要 使 用 JmsTemplate 提 供 的 方法 
来 进行 发 送 操作 ， 可 见 JmsTemplate 类 的 重要 性 ， 那 么 我 们 对 于 Spring 整 
合 消 息 服 务 的 分 析 就 从 JmsTemplate 开 始 。 

13.3.1 JmsTemplate 

在 代码 与 Spring 整合 的 实例 中 ， 我 们 看 到 Spring 采用 了 与 JDBC 等 一 
贯 的 套路 ， 为 我 们 提供 了 JmsTemplate 来 封装 常用 操作 。 查 看 
JmsTemplate 的 类 型 层级 结构 图 ， 如 图 13-1 所 示 。 





t [Dn H ~ 
4 © JmsTemplate 
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Q JmsOperations 








图 13-1 JmsTemplate 的 类 型 层级 结构 图 


首先 还 是 按照 一 贯 的 分 析 套 路 ， 提 取 我 们 感 兴趣 的 接口 
InitializingBean， 接 口 方法 实现 是 在 JmsAccessor 类 中 ， 如 下 : 
public void afterPropertiesSet() { 





if (getConnectionFactory() == null) { 
throw new IllegalArgumentException(" Property 
'connectionFactory' is required"); 
j 
j 
ACH PAAR ESE HRA EEK., THI PG 
索 ， 我 们 转 同 实例 代码 的 分 析 。 首 先 以 肥 送 为 例 ， 在 Spring 中 发 送 消 忆 
可 以 通过 JmsTemplate 中 提供 的 方法 来 实现 。 


public void send(final Destination destination, final MessageCreator 





messageCreator) 
throws JmsException 
fe 77 XUL P: 
jmsTemplate.send(destination, new MessageCreator() { 
public Message createMessage(Session session) throws 
JMSException { 


return session.createTextMessage(" 大 家 好 这 个 是 测试 ! "); 
} 

y 

我 们 就 跟 大 程序 流 ， 进 入 函数 send 但 看 其 源 代码 : 

public void send(final Destination destination, final MessageCreator 
messageCreator) 

throws JmsException { 

execute(new SessionCallback<Object>() { 
public Object doInJms(Session session) throws JMSException { 
doSend(session, destination, messageCreator); 
return null; 
} 
}, false); 

} 

现在 的 风格 不 得 不 让 我 们 回想 起 JdbcTemplate 的 类 实现 风格 ， 极 为 
相似 ， 都 是 提取 一 个 公共 的 方法 作为 最 底层 、 最 通用 的 功能 实现 ， 然 后 
又 通 过 回调 函数 的 不 同 来 区 分 个 性 化 的 功能 。 我 们 首先 查看 通用 代码 的 
抽取 实现 。 

1. 通用 代码 抽取 

根据 之 前 分 析 JdbcTemplate 的 经 验 ， 我 们 推断 ， 在 execute 中 一 定 是 
封装 了 Connection 以 及 Session 的 创建 操作 。 


public <T> T execute(SessionCallback<T> action, boolean 











startConnection) throws JmsException { 
Assert.notNull(action, "Callback object must not be null"); 
Connection conToClose = null; 
Session sessionToClose = null; 


try { 


Session sessionToUse = 
ConnectionFactoryUtils.doGetTransactionalSession( 
getConnectionFactory(), this.transactionalResourceFactory, 
startConnection); 
if (sessionToUse == null) { 
/创建 connection 
conToClose = createConnection(); 
/根据 connection 创 建 session 
sessionToClose = createSession(conToClose); 
FEB TTA AIRS aS ERS, AARC IY TER, 
发 送 时 不 需要 
if (startConnection) { 
conToClose.start(); 
} 
sessionToUse = sessionToClose; 
} 
if (logger.isDebugEnabled()) { 
logger.debug("Executing callback on JMS Session: "+ 
session ToUse); 
j 
/调用 回调 函数 
return action.doInJms(sessionToUse); 
} 
catch (JMSException ex) { 
throw convertJmsAccessException(ex); 
} 
finally { 


/关闭 session 

JmsUtils.closeSession(sessionToClose); 

/释放 连接 

ConnectionFactoryUtils.releaseConnection(conToClose, 
getConnectionFactory(), 


startConnection); 


} 

在 展示 单独 使 用 activeMQ 时 ， 我 们 知道 为 了 发 送 一 条 消息 需要 做 
很 多 工作 ， 需 要 很 多 的 辅助 代码 ， 而 这 些 代码 又 都 是 干 篇 一 律 的 ， 没 有 
任何 的 差异 ， 所 以 execute 方法 的 目的 人 
使 我 们 更 加 专注 于 业务 逻辑 的 实现 。 从 函数 中 看 ， 这 些 见 余 代码 包括 创 
建 Connection、 创 建 Session、 当 然 也 包括 关闭 Session 和 关闭 
Connection。 而 在 准备 工作 结束 后 ， 调 用 回调 函数 将 程序 引入 用 户 自 定 
义 实现 的 个 性 化 处 理 。 至 于 如 何 创 建 Session 与 Connection， 有 兴趣 的 读 
者 可 以 进一步 研究 Mybatis 的 源码 。 

2. 发 送 消息 的 实现 

有 了 基 类 辅助 实现 ， 使 Spring 更 加 专注 于 个 性 的 处 理 ， 也 就 是 说 
Spring 使 用 execute 方 法 中 封装 了 元 余 代 码 ， 而 将 个 性 化 的 代码 实现 放 在 
了 回调 函数 doImnJms 函 数 中 。 在 发 送 消 息 的 功能 中 回调 函数 通过 局 部 类 
实现 。 

new SessionCallback<Object>() { 








public Object doInJms(Session session) throws JMSException { 
doSend(session, destination, messageCreator); 


return null; 


此 时 的 发 送 逻 辑 已 经 完全 被 转向 了 doSend 方 法 ， 这 样 使 整个 功能 实 
现 变 得 更 加 清晰 。 

protected void doSend(Session session, Destination destination, 
MessageCreator 

messageCreator) 


throws JMSException { 
Assert.notNull(messageCreator, "MessageCreator must not be null"); 


MessageProducer producer = createProducer(session, destination); 


try { 
Message message = messageCreator.createMessage(session); 


if (logger.isDebugEnabled()) { 


logger.debug(" Sending created message: " + message); 


} 
doSend(producer, message); 
// Check commit - avoid commit call within a JTA transaction. 


if (session.getTransacted() && 


isSessionLocallyTransacted(session)) { 
// Transacted session created by this template -> commit. 


JmsUtils.commitIfNecessary(session); 


} 
finally { 
JmsUtils.closeMessageProducer(producer); 


} 


protected void doSend(MessageProducer producer, Message message) 


throws JMSException { 


if (isExplicitQosEnabled()) { 
producer.send(message, getDeliveryMode(), getPriority(), 
getTimeToLive()); 
j 
else { 


producer.send(message); 


} 

在 演示 独立 使 用 消息 功能 的 时 候 ， 我 们 大 体 了 解 了 消息 发 送 的 基本 
套路 ， 虽 然 这 些 步骤 已 经 被 Spring 拆 得 文 离 破碎 ， 但 是 我 们 还 是 能 捕捉 
到 一 些 影子 。 在 发 送 消息 还 是 遵循 着 消息 发 送 的 规则 ， 比 如 根据 
Destination 创 建 MessageProducer、 创 建 Message， 并 使 用 
MessageProducer SE f] 2K A XS 1H E. 
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那么 这 个 功能 Spring 是 如 何 封 装 的 呢 ? 


public Message receive(Destination destination) throws JmsException { 











return receiveSelected(destination, null); 
} 
public Message receiveSelected(final Destination destination, final 
String messageSelector) 
throws JmsException { 
return execute(new SessionCallback<Message>() { 
public Message doInJms(Session session) throws JMSException { 
return doReceive(session, destination, messageSelector); 
} 


}, true); 


} 
protected Message doReceive(Session session, Destination destination, 
String messageSelector) 
throws JMSException { 
return doReceive(session, createConsumer(session, destination, 
messageSelector)); 
} 
protected Message doReceive(Session session, MessageConsumer 
consumer) throws JMSException { 
try { 
// Use transaction timeout (if available). 
long timeout = getReceiveTimeout(); 
JmsResourceHolder resourceHolder = 
(JmsResourceHolder) 
TransactionS ynchronizationManager.getResource 
(getConnectionFactory()); 
if (resourceHolder != null && resourceHolder.hasTimeout()) { 
timeout = Math.min(timeout, 
resourceHolder.get l'imeToLiveInMillis()); 
j 
Message message = doReceive(consumer, timeout); 
if (session.getTransacted()) 1 
// Commit necessary - but avoid commit call within a JTA 
transaction. 
if (isSessionLocallyTransacted(session)) 1 
// Transacted session created by this template -> commit. 


JmsUtils.commitIf Necessary(session); 


} 

else if (isClientAcknowledge(session)) { 
// Manually acknowledge message, if any. 
if (message != null) { 


message.acknowledge(); 


} 

return message; 
} 
finally { 


JmsUtils.closeMessageConsumer(consumer); 


j 
private Message doReceive(MessageConsumer consumer, long timeout) 
throws JMSException 1 
if (timeout == RECEIVE TIMEOUT NO WAIT) { 
return consumer.receiveNoWait(); 
j 
else if (timeout > 0) 1 
return consumer.receive(timeout); 
j 
else { 


return consumer.receive(); 


) 
实现 的 套路 与 发 送 差不多 ， 同 样 还 是 使 用 execute 函数 来 封装 元 余 





的 公共 操作 ， 而 最 终 的 目标 还 是 通过 consumer.receive() 来 接收 消息 ， 其 
中 的 ee CE 的 创建 以 及 一 些 辅助 操作 。 


13.3.2 I5 rz Aas 


消息 监听 器 容器 是 一 个 用 于 查看 JMS 目标 等 待 消息 到 达 的 特 丈 
bean， 一 旦 消息 到 达 它 就 可 以 获取 到 消息 ， 并 通过 调用 onMessage() 方 法 
将 消息 传递 给 一 个 MessageListener 实 现 。Spring 中 消息 监听 器 容器 的 类 
m. 

SimpleMessageListenerContainer: Af FAME s dua. AA 
处 理 固定 数量 的 JMS 会 话 ， ON e 

DefaultMessageListenerContainer: 这 个 消息 监听 器 容 髓 建立 在 
SimpleMessageListener Container 容 器 之 上 ， 添 加 了 对 事务 的 文 持 。 

serversession.ServerSessionMessage.ListenerContainer: 这 是 功能 最 
强大 的 消息 监 昕 器， 与 DefaultMessageListenerContainer 相 同 ， 它 支持 事 
务 ， 但 是 它 还 允许 动态 地 管理 JMS 会 话 。 

下 面 以 DefaultMessageListenerContainer 为 例 进 行 分 析 ， 看 看 消息 
监听 霹 容 髓 的 实现 。 在 之 前 消息 监听 器 的 使 用 示例 中 ， 我 们 了 解 到 在 使 
用 消 妃 监听 器 容器 时 一 定 要 将 目 定 义 的 消 轧 监听 器 置 入 到 容器 中 ， 这 样 
才 可 以 在 收 到 信息 时 ， 容 器 把 消息 转 同 监听 器 处 理 。 碍 看 
DefaultMessageListenerContainer 层 次 结构 图 ， 如 图 13-2 所 示 。 
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图 13-2 DefaultMessageListenerContainer 层 次 结构 图 


同样 ， 我 们 看 到 此 类 实现 了 InitializingBean 接 口 ， 按 照 以 往 的 风格 
我 们 还 是 首先 查看 接口 方法 afterPropertiesSetO 中 的 逻辑 ， 其 方法 实现 在 
其 父 类 AbstractJmsListeningContainer 中 。 





public void afterPropertiesSet() { 
// 验 证 connectionFactory 
super.afterPropertiesSet(); 
// 验 证 配置 文件 
validateConfiguration(); 
/初始 化 
initialize(); 
j 
监听 器 容器 的 初始 化 只 包含 了 三 句 代码 ， 其 中 前 两 句 只 用 于 属性 的 
验证 ， 比 如 connectionFacory 或 者 destination 等 属性 是 否 为 空 等 ， 而 真正 
用 于 初始 化 的 操作 委托 在 initialize() 中 执行 。 








public void initialize() throws JmsException 1 
try 1 
/lifecycleMonitor 用 于 控制 生命 周期 的 同步 处 理 
synchronized (this.lifecycleMonitor) { 
this.active = true; 
this.lifecycleMonitor.notifyAIl(); 
j 
dolInitialize(); 
j 
catch (JMSException ex) 1 


synchronized (this.sharedConnectionMonitor) { 


ConnectionFactoryUtils.releaseConnection(this.sharedConnection, 
getConnectionFactory(), this.autoStartup); 
this.sharedConnection - null; 


} 


throw convertJmsAccessException(ex); 


} 
protected void dolnitialize() throws JMSException 1 
synchronized (this.lifecycleMonitor) { 
for (int i = 0; i < this.concurrentConsumers; i++) { 


scheduleNewInvoker(); 


} 
这 里 用 到 了 concurrentConsumers 必 性， 网 络 中 对 此 属性 用 法 的 说 明 


如 下 。 

消息 监听 器 允许 创建 多 个 Session 和 MessageConsumer 来 接收 消 
息 。 有 具体 的 个 数 由 concurrentConsumers 属 性 指定 。 需 要 注意 的 是 ， 应 该 
只 是 在 Destination 为 Queue 的 时 候 才 使 用 多 个 MessageConsumer (Queue 
中 的 一 个 消息 只 能 被 一 个 Consumer 接收 ) ， 虽 然 使 用 多 个 
MessageConsumer 会 提高 消息 处 理 的 性 能 ， 但 是 消息 处 理 的 顺序 却 得 不 
到 保证 。 消 息 被 接收 的 顺序 仍然 是 消息 发 送 时 的 顺序 ， 但 是 由 于 消 轧 可 
能 会 被 并 发 处 理 ， 因 此 消息 处 理 的 顺序 可 能 和 消息 发 送 的 顺序 不 同 。 此 
外 ， 不 应 该 在 Destination 为 Topic 的 时 候 使 用 多 个 MessageConsumer， 
为 多 个 MessageConsumer 会 接收 到 同样 的 消 筷 。 

对 于 具体 的 实现 逻辑 我 们 只 能 继续 查看 源码 : 


private void scheduleNewInvoker() 1 











AsyncMessageListenerInvoker invoker = new 
AsyncMessageListenerInvoker(); 
if (rescheduleTaskIfNecessary(invoker)) { 
// This should always be true, since we're only calling this when active. 
this.scheduledInvokers.add(invoker); 
} 
} 
protected final boolean rescheduleTaskIfNecessary(Object task) 1 
if (this.running) { 
try 1 
doRescheduleTask(task); 
j 
catch (RuntimeException ex) 1 
logRejectedTask(task, ex); 
this.pausedTasks.add(task); 


} 
return true; 

} 

else if (this.active) { 
this.pausedTasks.add(task); 
return true; 

} 

else { 


return false; 


} 
protected void doRescheduleTask(Object task) { 
this.taskExecutor.execute((Runnable) task); 

} 

分 析 源 码 得 知 ， 根 据 concurrentConsumers 数 量 建立 了 对 应 数量 的 线 
程 ， 即 使 读者 不 了 解 线程 池 的 人 使用， 至少 根据 以 上 代码 可 以 推 央 出 
doRescheduleTask 了 消 数 其 实 是 在 开启 一 个 线程 执行 Runnable。 我 们 反 追 
踪 这 个 传 入 的 参数 ， 可 以 看 到 这 个 参数 其 实 是 
AsyncMessageListenerInvoker 类 型 实例 。 因 此 我 们 可 以 推 新 ，Spring 根 据 
concurrentConsumers 数 量 建立 了 对 应 数量 的 线程 ， 而 每 个 线程 都 作为 一 
个 独立 的 接收 者 在 循环 接收 消息 。 








实现 ， 由 于 它 是 作为 一 个 Runnable 角 色 去 执行 ， 所 以 对 以 这 个 类 的 分 析 
从 run 方 法 开始 。 
public void run() 1 
1/ 并 发 控制 


synchronized (lifecycleMonitor) { 


activeInvokerCount++; 
lifecycleMonitor.notifyAll(); 
j 
boolean messageReceived = false; 
try 1 
IT A REA TE A6 CELER pt CK AERIS A CERE TIU E AP [e] A E 
1/ 小 于 0 默认 为 无 限制 ， 一 直接 收 消息 
if (maxMessagesPerTask < 0) { 








messageReceived = executeOngoingLoop(); 
} 
else { 

int messageCount = 0; 
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while (isRunning() && messageCount < maxMessagesPerTask) 


{ 
messageReceived = (invokeListener() || messageReceived); 
messageCount++; 
} 
} 
} 
catch (Throwable ex) { 
/清理 操作 ， 包 括 关 闭 session 等 
clearResources(); 
if (!this.lastMessageSucceeded) { 
// We failed more than once in a row - sleep for recovery 
interval 


// even before first recovery attempt. 


sleepInbetweenRecoveryAttempts(); 


} 
this.lastMessageSucceeded = false; 
boolean alreadyRecovered = false; 
synchronized (recoveryMonitor) { 
if (this.lastRecoveryMarker == currentRecoveryMarker) { 
handleListenerSetupFailure(ex, false); 
recoverA fterListenerSetupFailure(); 


currentRecoveryMarker = new Object(); 


} 


else { 


alreadyRecovered = true; 


} 
if (alreadyRecovered) { 


handleListenerSetupFailure(ex, true); 


} 
finally { 
synchronized (lifecycleMonitor) { 
decreaseActiveInvokerCount(); 
lifecycleMonitor.notify All(); 
j 
if (ImessageReceived) { 


this.idleTaskExecutionCount++; 
} 


else { 


this.idleTaskExecutionCount = 0; 
} 
synchronized (lifecycleMonitor) { 
if (IshouldRescheduleInvoker(this.idleTaskExecutionCount) || 
!Ireschedule 
TaskIfNecessary(this)) 1 
// We're shutting down completely. 
scheduledInvokers.remove(this); 
if (logger.isDebugEnabled()) { 
logger.debug("Lowered scheduled invoker count: " + 
scheduledInvokers.size()); 
j 
lifecycleMonitor.notify All(); 
clearResources(); 
j 
else if (isRunning()) 1 
int nonPausedConsumers = getScheduledConsumerCount() - 
getPausedTaskCount(); 
if (nonPausedConsumers « 1) { 
logger.error(" All scheduled consumers have been paused, 
probably due to tasks having been rejected. " + 
"Check your thread pool configuration! Manual 
recovery necessary through a start() call."); 
j 
else if (nonPausedConsumers < getConcurrentConsumers()) { 
logger.warn("Number of scheduled consumers has dropped 


below concurrentConsumers limit, probably " + 


"due to tasks having been rejected. Check your 
thread pool configuration! Automatic recovery " + 


"to be triggered by remaining consumers."); 


} 
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况 处 理 ， 当 然 ， 函 数 中 还 使 用 了 大 量 的 代码 处 理 异 常 机 制 的 数据 维护 ， 
但 是 我 相信 大 家 跟 我 一 样 更 加 关注 程序 的 正常 流程 是 如 何 处 理 的 。 

其 实 核心 的 处 理 就 是 调用 invokeListener 来 接收 消息 并 激活 消息 监 
听 器 ， 但 是 之 所 以 两 种 情况 分 开 处 理 ， 正 是 考虑 到 在 无 限制 循环 接收 消 
ATS 下， 用户 可 以 通过 设置 标志 位 running 来 控制 消 虫 接收 的 暂停 与 
恢复 ， 并 维护 当前 消息 监听 器 的 数量 。 


private boolean executeOngoingLoop() throws JMSException { 





boolean messageReceived = false; 
boolean active = true; 
while (active) { 
synchronized (lifecycleMonitor) { 
boolean interrupted = false; 
boolean wasWaiting = false; 


/如 果 当 前 任务 已 经 处 于 激活 状态 但 是 却 给 了 暂时 终止 的 命 


dp 


while ((active = isActive()) && !isRunning()) 1 
if (interrupted) 1 


throw new IllegalStateException(" Thread was interrupted 


while waiting for " + 
"a restart of the listener container, but 

container is still stopped"); 
j 
if ("wasWaiting) 1 

/如 果 并 非 处 于 等 待 状 态 则 说 明 是 第 一 次 执行 ， 需 要 将 

激活 任务 数量 减少 

decreaseActiveInvokerCount(); 
} 
/开始 进入 等 待 状态 ， 等 待 任务 的 恢复 命 


wasWaiting = true; 


try { 
/通过 wait 等 待 ， 也 就 是 等 竺 notify 或 者 notifyAll 
oe. 

} 


catch (InterruptedException ex) { 
// Re-interrupt current thread, to allow other threads 
to react. 
Thread.currentThread().interrupt(); 


interrupted = true; 


} 
if (wasWaiting) { 
activeInvokerCount++; 
i 
if (scheduledInvokers.size() > maxConcurrentConsumers) { 


active = false; 


} 
/正常 处 理 流 程 
if (active) { 


messageReceived = (invokeListener() || messageReceived); 


} 
return messageReceived; 
} 
如 果 按 照 正 第 的 流程 其 实 是 不 会 进入 while 循 环 中 的 ， 而 是 直接 进 
入 函数 invokeListener(0 来 接收 消息 并 激活 监听 器 ， 但 是 ， 我 们 不 可 能 让 
循环 一 直 持 续 下 去 ， 我 们 要 考虑 到 暂停 线程 或 者 恢复 线程 的 情况 ， 这 
IN, isRunning() KRZYK EHH T . 
isRunning() 用 来 检测 标志 位 this.running 状 态 进 而 判断 是 否 需 要 进入 
while 循 环 。 由 于 要 维护 当前 线程 激活 数量 ， 所 以 引入 了 wasWaiting 变 
量 ， 用 来 判断 线程 是 否 处 于 等 竺 状态 。 如 果 线 程 首次 进入 等 竺 状态 ， 则 
需要 减少 线程 激活 数量 计数 器 。 
当然 ， 还 有 一 个 地 方 需要 提 一 下 ， 就 是 线程 等 待 不 是 一 味 地 采用 
while 循 环 来 控制 ， 因 为 如 果 单 纯 地 采用 while 循 环 会 浪费 CPU 的 始终 周 
期 ， 给 资源 造成 巨大 的 浪费 。 这 里 ，Spring 采 用 的 是 使 用 全 局 控制 变量 
lifecycleMonitor 的 wait() 方 法 来 暂停 线程 ， 所 以 ， 如 果 终 止 线程 需要 再 次 
恢复 的 话 ， 除 了 更 改 this.running 标 志 位 外 ， 还 需要 调用 
lifecycleMonitor.notify 或 者 lifecycle Monitor.notifyAll 来 使 线程 恢复 。 
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private boolean invokeListener() throws JMSException { 
/初始 化 资源 包括 首次 创建 的 时 候 创 建 session 与 consumer 


initResourcesIfNecessary(); 











boolean messageReceived = receiveAndExecute(this, this.session, 
this.consumer); 
/改变 标志 位 ， 信 息 成 功 处 理 
this.lastMessageSucceeded = true; 
return messageReceived; 
} 
protected boolean receiveAndExecute(Object invoker, Session session, 
MessageConsumer 
consumer) 
throws JMSException { 
if (this.transactionManager != null) { 
// Execute receive within transaction. 
TransactionStatus status = 
this.transactionManager.getTransaction(this. 
transactionDefinition); 
boolean messageReceived; 
try { 
messageReceived = doReceiveAndExecute(invoker, session, 
consumer, status); 
} 
catch (JMSException ex) { 
rollbackOnException(status, ex); 
throw ex; 
} 
catch (RuntimeException ex) { 
rollbackOnException(status, ex); 


throw ex; 


} 
catch (Error err) { 
rollbackOnException(status, err); 
throw err; 
} 
this.transactionManager.commit(status); 
return messageReceived; 
} 
else { 
// Execute receive outside of transaction. 


return doReceiveAndExecute(invoker, session, consumer, null); 


} 

在 介绍 消息 监听 器 容器 的 分 类 时 ， 已 介绍 了 
DefaultMessageListenerContainer 消息 监听 器 容器 建立 在 
SimpleMessageListenerContainer 容 器 之 上 ， 添 加 了 对 事务 的 文 持 ， 那 么 
此 时 ， 事 务 特性 的 实现 已 经 开始 了 。 如 果 用 户 配 置 了 
this.transactionManager ， 也 就 是 配置 了 事务 ， 那 么 ， 消 息 的 接收 会 被 控 
制 在 事务 之 内 ， 一 旦 出 现任 何 异常 都 会 被 回 深 ， 而 回 深 操 作 也 会 交 由 事 
务 管理 器 统一 处 理 ， 比 如 this.transactionManager.rollback(status)。 

doReceiveAndExecute 包含 了 整个 消息 的 接收 处 理 过 程 ， 由 于 参 杂 
着 事务 ， 所 以 并 没有 复 用 模板 中 的 方法 。 


protected boolean doReceiveAndExecute( 








Object invoker, Session session, MessageConsumer consumer, 
TransactionStatus 
status) 


throws JMSException { 


Connection conToClose = null; 
Session sessionToClose = null; 
MessageConsumer consumerToClose = null; 
try { 
Session sessionToUse = session; 
boolean transactional = false; 
if (sessionToUse == null) { 
session ToUse = 
ConnectionFactoryUtils.doGetTransactionalSession( 
getConnectionFactory(), this.transactionalResourceFactory, 
true); 
transactional = (sessionToUse !- null); 
j 
if (sessionToUse == null) { 
Connection conToUse; 
if (sharedConnectionEnabled()) 1 
conToUse = getSharedConnection(); 
} 
else { 
conToUse = createConnection(); 
conToClose = conToUse; 
conToUse.start(); 
} 
sessionToUse = createSession(conToUse); 
sessionToClose = sessionToUse; 


} 


MessageConsumer consumerToUse = consumer; 


if (consumerToUse == null) { 
consumerToUse = createListenerConsumer(sessionToUse); 
consumerToClose = consumerToUse; 
} 
/接收 消息 
Message message = receiveMessage(consumerToUse); 
if (message != null) { 
if (logger.isDebugEnabled()) { 
logger.debug(" Received message of type [" + 
message.getClass() * 
"| from consumer [" + 
consumerToUse + "] of " + (transactional ? "transactional 
"> "") + "session [" + 
sessionToUse + "J"; 
} 
/模板 方法 ， 当 消息 接收 且 在 未 处 理 前 给 子 类 机 会 做 相应 
处 理 ， 当 期 空 实现 
messageReceived(invoker, sessionToUse); 
boolean exposeResource = (!transactional && 
isExposeListenerSession() && 
!'TransactionS ynchronizationManager.hasResource 
(getConnection 
Factory())); 
if (exposeResource) { 
TransactionSynchronizationManager.bindResource( 
getConnectionFactory(), new LocallyExposedJms 


Resource 


Holder(sessionToUse)); 
} 
try { 
/激活 监听 器 
doExecuteListener(sessionToUse, message); 
} 
catch (Throwable ex) { 
if (status != null) { 
if (logger.isDebugEnabled()) { 


logger.debug("Rolling back transaction because of listener exception 
thrown: " + ex); 


j 
status.setRollbackOnly(); 
} 
handleListenerException(ex); 
// Rethrow JMSException to indicate an infrastructure problem 
// that may have to trigger recovery... 
if (ex instanceof JMSException) { 
throw (JMSException) ex; 


} 
finally { 
if (exposeResource) { 


TransactionSynchronizationManager.unbindResource&nbsp; 
(getConnectionFactory()); 


} 


// Indicate that a message has been received. 
return true; 
} 
else { 
if (logger.isTraceEnabled()) { 
logger.trace(" Consumer [" + consumerToUse + "] of " + (transactional ? 
"transactional " : "") + "session [" + sessionToUse + "| did not receive a 
message"); 
j 
/接收 到 空 消息 的 处 理 
noMessageReceived(invoker, sessionToUse); 
// Nevertheless call commit, in order to reset the transaction timeout 
(if&nbsp;any). 
// However, don't do this on Tibco since this may lead to a 
deadlock&nbsp;there. 
if (shouldCommitA fterNoMessageReceived(sessionToUse)) 1 
commitIfNecessary(sessionToUse, message); 
j 
// Indicate that no message has been received. 
return false; 
j 
j 
finally 1 
JmsUtils.closeMessageConsumer(consumerToClose); 
JmsUtils.closeSession(sessionToClose); 
ConnectionFactoryUtils.releaseConnection(conToClose, 


getConnectionFactory(),&nbsp;true); 


} 
上 面 函 数 代码 看 似 楷 杂 ， 但 是 真正 的 多 辑 并 不 多 ， 大 多 是 固定 的 套 
路 ， 而 我 们 最 关心 的 就 是 监听 喜 的 激活 处 理 。 


protected void doExecuteListener(Session session, Message message) 





throws JMSException { 
if ('isAcceptMessagesWhileStopping() && !isRunning()) { 
if (logger.isWarnEnabled()) { 
logger.warn("Rejecting received message because of the listener 
container " + "having been stopped in the meantime: " + message); 
j 
rollbackIfNecessary(session); 
throw new MessageRejectedWhileStoppingException(); 
j 
try 1 
invokeListener(session, message); 
j 
catch (JMSException ex) 1 
rollbackOnExceptionIf Necessary(session, ex); 
throw ex; 
j 
catch (RuntimeException ex) 1 
rollbackOnExceptionIf Necessary(session, ex); 
throw ex; 
j 
catch (Error err) { 


rollbackOnExceptionIfNecessary(session, err); 


throw err; 


} 


commitIfNecessary(session, message); 


} 
protected void invokeListener(Session session, Message message) 
throws JMSException { 
Object listener = getMessageListener(); 
if (listener instanceof SessionAwareMessageListener) { 


doInvokeListener((SessionAwareMessageL istener) listener, 


session, message); 
j 
else if (listener instanceof MessageListener) { 
doInvokeListener((MessageListener) listener, message); 
} 
else if (listener != null) { 
throw new IllegalArgumentException( "Only MessageListener and 


SessionA wareMessageListener supported: " + listener); 


} 
else { 
throw new IllegalStateException("No message listener specified - see 
property 'messageListener'"); 
j 
} 


protected void doInvokeListener(MessageListener listener, Message 


message) throws JMSException { 


listener.onMessage(message); 


通过 层 层 调用 ， 最 终 提取 监听 器 并 使 用 listener.onMessage(message) 
激活 了 监听 器 ， 也 就 是 激活 了 用 户 自 定义 的 监听 器 逻辑 。 这 里 还 有 一 名 
重要 的 代码 很 容易 被 忽略 掉 ，commitIfNecessary(session, message), Fë 
成 的 功能 是 session.commit()。 完 成 消 恩 服务 的 事务 提交 ， 涉 及 两 个 事 
务 ， 我 们 和 党 说 的 DefaultMessageListenerContainer 增 加 了 事务 的 支持 ， 是 
通用 的 事务 ， 也 就 是 说 我 们 在 消息 接收 过 程 中 如 果 产 生 其 他 操作 ， 比 如 
向 数据 库 中 插入 数据 ， 一 旦 出 现 异 常 时 就 需要 全 部 回 滚 ， 包 括 回 滚 插入 
数据 库 中 的 数据 。 但 是 ， 除 了 我 们 常 说 的 事务 之 外 ， 对 于 消 奶 本 里 还 有 
一 个 事务 ， 当 接收 一 个 消息 的 时 候 ， 必 须 使 用 事务 提交 的 方式 ， 这 是 在 
告诉 消息 服务 器 本 地 已 经 正音 接收 消息 ， 消 息 服 务 器 接收 到 本 地 的 事务 
提交 后 便 可 以 将 此 消息 删除 ， 否 则 ， 当 前 消息 会 被 其 他 接收 者 重新 接 
收 。 
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